On 29 March 2013 15:16, Jason Pickering <[email protected]> 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 <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
