Stop right there. Your configuration is crazy. You don't need a billion worker processes, a good start is core/hardware thread count x 2, and increase it if CPU is not saturated. Each worker requires anything from 10 to 200MB of RAM depending on the software you run, specifying a max of 200 is a good way to kill a server. If you've ever run Apache-prefork with max clients set to 200 you'll know what I mean.
Secondly, you're benchmarking the wrong thing. What's up with people benchmarking no-op's and super simple scripts? Try a Wordpress, MediaWiki or PhpBB installation instead. Without software doing actual work, all you measure is some number that have zero meaning. On a real site, your throughput/concurrency is limited by: - Frontend performance and concurrent socket limit. Configure Nginx to be able to handle the amount of concurrent requests and idle keep alive connections. We handle a few M requests a day with 10 processes x 2048 connections each, 30s keepalive. Keep alive is critical to keep the actual browser measured performance high when multiple requests are issued, skipping the TCP 3 way handshake delay. ab cannot measure this, but jmeter can up to a certain limit. Script some virtual uses that goes to /, wait 10s, then clicks on /viewforum.php?f=2, wait 5s, then clicks on a thread, and see how many users you can run without timeouts / slowdowns. That number is huge and more than you'll ever need unless you run a huge site with a million+ unique visitors. - Worker (uwsgi) concurrency. In our config, listen = 1000 creates a buffer when many many requests hit at once, and processes = 40 on each 16 thread server to keep all the cores busy. The actual software uses 300MB per process, upping the limit will just increase the memory usage with zero benefit. To avoid socket timeouts and rejected connections, make sure you have enough space in the listen queue, bump ulimit -n, check sysctl, etc etc. If you get an error with just -c 200, you have an configuration error somewhere. Kind regards, -- Chi Ho Kwok Digibites Technology [email protected] On 25 September 2013 13:45, Darko Luketic <[email protected]> wrote: > Yes > > [uwsgi] > plugins = php > master = true > processes = 300 > cheaper = 2 > php-allowed-ext = .php > uid = darko > gid = users > socket = /tmp/uwsgi-%n.sock > disable_logging = true > listen = 16384 > > > > On 25.09.2013 12:59, Łukasz Mierzwa wrote: > > Do you have enough workers to handle 200 concurrent requests? Requests are > queuing in backlog waiting for your app to process them (default backlog is > 100 requests), once the queue is full you will get connect() error. > > > 2013/9/25 Darko Luketic <[email protected]> > >> Hello, >> >> I was doing a simple ab -n10000 -c200 test >> with various php projects locally. >> >> And the results across all tests were ~9800 non 2xx responses. >> Now I've read the error log and it said: >> connect() to unix:/tmp/uwsgi-php.sock failed (11: Resource temporarily >> unavailable) while connecting to upstream >> Now I've googled and apparently that errormessage says that the socket is >> blocking and the connection was blocked because of too many processes >> trying to query it. >> >> My question is, how do I increase this limitation? >> >> cat /proc/sys/fs/file-max >> 3249525 >> >> ipcs -l >> >> ------ Messages Limits -------- >> max queues system wide = 32768 >> max size of message (bytes) = 8192 >> default max size of queue (bytes) = 16384 >> >> ------ Shared Memory Limits -------- >> max number of segments = 4096 >> max seg size (kbytes) = 32768 >> max total shared memory (kbytes) = 8388608 >> min seg size (bytes) = 1 >> >> ------ Semaphore Limits -------- >> max number of arrays = 128 >> max semaphores per array = 250 >> max semaphores system wide = 32000 >> max ops per semop call = 32 >> semaphore max value = 32767 >> >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > > > > -- > Łukasz Mierzwa > > > _______________________________________________ > uWSGI mailing > [email protected]http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
