You were right. Thank you very much ?ukasz.
This sheds a completely different light.
It also explains why the first 9k requests passed so quickly and the
last 1k took longer.
I did the same with node.js and the express framework, raw node and
node+nginx.
The results blow me away.
requests/second
~3k for node/express ~200 more w/o nginx
raw php <?php echo "Hello World"; ?>
~7.2k
symfony 2.3.4, not a hello world app but no db queries
~20 , yes 20 not 20k
The same thing on Ubuntu with apache 2.2.22 and php-fpm, no failed
requests, same machine, a while back.
~14.4k raw php
~580 sf 2.2.1 hello world app
~6.1k php with phalcon hello world
~6.7k spring on tomcat 7.0.39 vanilla hello world app
This is weird. How can there be such a big difference?
I set nginx to 200 processes 1024 workers, btw no difference if 1
process 1024 workers or 200 processes 1024 workers.
The only thing that is different is that the projects are on a striped
zfs drive vs a lvm ext4 single partition and well php frameworks do a
lot of reading of files because of autoloading, many files - many files
accessed.
Are there other options to make the php plugin perform better? I know it
sounds like a lazy question, I'm also reading the docs and trying to
find something. It seems like uwsgi was written primarily for python, I
can't tell which option affects php and which doesn't. For instance
would threads work with php? If yes php would have to be compiled with zts.
Of course I'm aware ab isn't a ... realistic load and concurrency
testing tool it only serves as an indicator.
On 25.09.2013 13:50, ?ukasz Mierzwa wrote:
> cheaper = 2
your app will get hit with all 200 initial requests at once but only 2
workers, it will take some time to spawn those 198 additional
processes needed to handle 200 concurrent requests is
such scenario. This is why you had those connection errors with
default listen queue.
2013/9/25 Darko Luketic <[email protected] <mailto:[email protected]>>
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 <tel:25.09.2013%2012>: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] <mailto:[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] <mailto:[email protected]>
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
--
?ukasz Mierzwa
_______________________________________________
uWSGI mailing list
[email protected] <mailto:[email protected]>
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
_______________________________________________
uWSGI mailing list
[email protected] <mailto:[email protected]>
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
--
?ukasz Mierzwa
_______________________________________________
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
