On 18/07/2011, at 8:00 PM, [email protected] wrote: > Send uWSGI mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of uWSGI digest..." > > > Today's Topics: > > 1. Avoiding 504's (Daryl Antony) > 2. Re: Avoiding 504's (Roberto De Ioris) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Jul 2011 10:53:13 +1000 > From: Daryl Antony <[email protected]> > To: [email protected] > Subject: [uWSGI] Avoiding 504's > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=us-ascii > > From time to time, we have a lot of 504's 'gateway timeouts'. I've attempted > to remedy this by increasing the time out under Cherokee, in the Behaviour > > Restrictions > Connections Timeout > > However, I wonder if there's something we could also set in our uWSGI xml -- > of which we have 2 sources, running in Round Robin > > <uwsgi> > > <pythonpath>/home/wwwdeploy/deployment/current/</pythonpath> > <pythonpath>/home/wwwdeploy/deployment/current/deploy/</pythonpath> > > <pythonpath>/home/wwwdeploy/deployment/virtual_env/lib/python2.6/site-packages/</pythonpath> > > <socket>/tmp/alpha.www.architecturemedia.sock</socket> > <home>/home/wwwdeploy/deployment/virtual_env/</home> > > <app mountpoint="/"> > <script>wsgi</script> > </app> > <touch-reload>/home/wwwdeploy/deployment/content/reload</touch-reload> > <master/> > <workers>2</workers> > <memory-report/> > <harakiri-verbose/> > <single-interpreter/> > <reload-mercy>8</reload-mercy> > <max-requests>1000</max-requests> > <cache>1000</cache> > </uwsgi> > > <uwsgi> > > <pythonpath>/home/wwwdeploy/deployment/current/</pythonpath> > <pythonpath>/home/wwwdeploy/deployment/current/deploy/</pythonpath> > > <pythonpath>/home/wwwdeploy/deployment/virtual_env/lib/python2.6/site-packages/</pythonpath> > > <socket>/tmp/beta.www.architecturemedia.sock</socket> > <home>/home/wwwdeploy/deployment/virtual_env/</home> > > <app mountpoint="/"> > <script>wsgi</script> > </app> > <touch-reload>/home/wwwdeploy/deployment/content/reload</touch-reload> > <master/> > <workers>2</workers> > <memory-report/> > <harakiri-verbose/> > <single-interpreter/> > <reload-mercy>8</reload-mercy> > <max-requests>1000</max-requests> > <cache>1000</cache> > </uwsgi> > > > > > ------------------------------ > > Message: 2 > Date: Mon, 18 Jul 2011 07:48:57 +0200 > From: Roberto De Ioris <[email protected]> > To: uWSGI developers and users list <[email protected]> > Subject: Re: [uWSGI] Avoiding 504's > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Il giorno 18/lug/2011, alle ore 02.53, Daryl Antony ha scritto: > >> From time to time, we have a lot of 504's 'gateway timeouts'. I've >> attempted to remedy this by increasing the time out under Cherokee, in the >> Behaviour > Restrictions > Connections Timeout >> >> However, I wonder if there's something we could also set in our uWSGI xml -- >> of which we have 2 sources, running in Round Robin >> > > > > You can try to add more workers. Check if you have http upload running in > your app. Remember that cherokee is a streaming server so while you upload a > worker is fully blocked. > -- > Roberto De Ioris > http://unbit.it > >
Oh I see. So we have admin users that are using Django Filebrowser, and it's multiple 'upload files/images' functionality... and possibly, that can absorb many of the workers and perhaps produce the timeouts? The site will run several sites for architecture magazines, and most of the content as attached, high quality, images. I had an idea to run the 'admin' under a different Cherokee vServer, therefore a different set of processes... Actually... I just took a look at the process running on our server via htop... seems the cherokee-workers are chewing up all of the CPUs, both screaming at 100% -- maybe I should be writing to a different mailing list :) > > ------------------------------ > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > End of uWSGI Digest, Vol 22, Issue 22 > ************************************* _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
