For some reason when I changed from TCP to socket file I get 503 Service Unavailable with no errors in uwsgi log:
tail uwsgi.log *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 7384) spawned uWSGI worker 1 (pid: 7392, cores: 1) set cpu affinity for worker 1 to 0 1 2 spawned uWSGI worker 2 (pid: 7393, cores: 1) set cpu affinity for worker 2 to 3 0 1 spawned uWSGI worker 3 (pid: 7394, cores: 1) set cpu affinity for worker 3 to 2 3 0 spawned uWSGI worker 4 (pid: 7395, cores: 1) set cpu affinity for worker 4 to 1 2 3 On Fri, Jul 6, 2012 at 1:49 PM, Łukasz Mierzwa <[email protected]> wrote: > Dnia piątek, 6 lipca 2012 12:53:25 Ryan Showalter pisze: > > On Fri, Jul 6, 2012 at 12:21 PM, Bruce Wade <[email protected]> > wrote: > > > Thanks I have changed that setting. > > > > > > Is there anything else that jumps out from my configuration that could > > > help > > > performance? > > > > I don't have much experience managing this specific sort of setup, but > > 4 workers to manage 500 simultaneous connections seems a little low > > depending on how long it's taking you to serve each request. Try > > bumping up the number of workers on each node to 8 and see if that > > helps at all. > > Or let uWSGI spawn additional workers if needed: > > [uwsgi] > processes = <max number of workers> > cheaper = <mininum number workers> > > See http://lists.unbit.it/pipermail/uwsgi/2011-September/002625.html > > It's hard to saturate single core with just one worker since it might wait > for > external resources like memcached, db or client, 2-4 workers per core seems > like a good starting point, but check how many workers can fit in ram > before > you start setting very high max number of workers. Once you're out of > memory > and you hit swap all the performance of fast server is gone. If you use > cgroup > memory limits in uWSGI than it will start swapping workers memory to disk > once > they eat all memory they can. > If you use max-requests or memory limits in uWSGI config than check how > long > does it take in peak hours to hit that limit and reload worker, it might > happen to frequently, and if your app takes to long to start it might slow > everything down. > Keep in mind that high number of workers may hit max database connection > limit > (it depends on db you use). > As always - if you can benchmark you workers, apache benchmark or siege are > good enough to get some idea of how many request per second you can get. > > Also - if you can change the way nginx talks to uwsgi - instead of local > tcp > connection use file socket - you want hammer tcp stack with a lot of > connections. > > in uwsgi config use: "socket = /var/run/uwsgi.socket" > in nginx config use: "uwsgi_pass unix:///var/run/uwsgi.socket;" > > Łukasz Mierzwa > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.fittraineronline.com - Fitness Personal Trainers Online http://www.warplydesigned.com
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
