dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 29 March 2013 15:16, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> I think this is a good and simple starting point. The only issue I see for
> this is another situation, where mutliple DHIS2 instances are running on the
> same machine, but under a different virtual host. This is simple enough with
> the "server_name" directive, so we might need to at least document this. Not
> exactly sure how common this is, but might be good to include it anyway.

Yes I can see this would be a different way of "fronting".  I am going
to concentrate on one approach for now where the webapp is mapped into
the url of a single host, but maybe we could consider scripting the
virtualhost setup as well in the future.

>
> Regards,
> Jason
>
>
>
> On Thu, Mar 28, 2013 at 7:15 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> I've run a few experiments with nginx and caching, verified with tcpdump.
>>
>> Attached is my suggestion for an nginx conf file dealing with multiple
>> tomcat backends.
>>
>> A few things to note:
>> 1.  this is not a full nginx.conf, but rather /etc/nginx/conf.d/dhis2
>> as you would find when installing nginx from deb (which I am going to
>> recommend)
>> 2.  I've done the proxy pass configs as one-liners which should make
>> easy for scriptable editing with sed
>> 3.  after lots of fiddling with the static content business I have
>> just dropped it for now.  What I have found and confirmed (at least
>> with chrome) is that chrome is caching this content anyway so there is
>> only very marginal utility in getting it served by nginx directly from
>> the file system.  It will only be required occasionally.  The nginx
>> cache doesn't work quite like the apache one in that this stuff is not
>> automatically being cached by the proxy.  If it did then this would
>> far and away be the simplest way to get served directly off the
>> filesystem.  I guess in order to make this happen we have to set the
>> Cache-Control headers with interceptors from within the webapp.  Which
>> I think this is the right way to go about it anyway.  Using the proxy
>> to fiddle with cache-control headers feels wrong.   Either way,
>> because of the browser caching behaviour its actually a pretty small
>> optimisation so I'm happy to lose it for now.
>>
>> Any comments on the conf file?
>>
>> Bob
>>
>> PS.  contrary to popular opinion I think the apache config is actually
>> much more straightforward, but for the moment it looks like nginx is
>> clearly superior on memory usage which I think is our primary concern
>> in most cases.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>