Simple threading question

Hi,

I have a bunch of nginx and php-fpm worker threads. I am running a
very simple test with a script doing: <? sleep(20); ?>. I notice that
if I make two requests at the same time (from the same IP address), they
get
serialized on the
php-fpm side and have a twenty second differential. Why would this
happen and the two requests not get processed in parallel when there
are an abundant number of threads? Here are the two requests in the
slow log file and they have a twenty second difference:

Sep 26 19:02:38.177091 pid 13597 (pool default)
script_filename = /var/www/test1/test.php
[0x00000000095b5280] sleep() /var/www/test1/test.php:2

Sep 26 19:02:58.321560 pid 13609 (pool default)
script_filename = /var/www/test1/test.php
[0x000000000942a890] sleep() /var/www/test1/test.php:2

I have 100+ nginx threads
$ ps -afe | grep nginx | wc -l
120

and 150 php-fpm threads
$ ps -afe | grep php-fpm | wc -l
150

Thanks,
Ankur

nginx doesnt need 100+ threads, it uses an event worker model. Set
your worker_processes to something more reasonable. If you are trying
to handle 150 requests then you really only need a single worker.

I can change the number of threads but my question is something
completely
orthogonal to what you replied. Why did the two server requests to
php-fpm
get serialized and not happen in parallel even though there are enough
worker threads?

On Sun, Sep 26, 2010 at 11:05:00PM -0700, Ankur G. wrote:

120

and 150 php-fpm threads
$ ps -afe | grep php-fpm | wc -l
150

nginx does not serialize requests to FastCGI. A single nginx worker can
handle tens thousand concurrent FastCGI connections.


Igor S.
http://sysoev.ru/en/

On 27/09/2010 07:50, Ankur G. wrote:

I can change the number of threads but my question is something
completely orthogonal to what you replied. Why did the two server
requests to php-fpm get serialized and not happen in parallel even
though there are enough worker threads?

It may be that nginx is proxying to the same php process, which has
multiple threads, and your sleep command in that thread is causing the
process to sleep. I’ve found that the best set-up is 1/2 nginx workers
(depending on how many CPUs/cores you’re running and how much SSL
traffic you have), multiple PHP processes, each running a small number
(<5) threads. Specifically, or main production server runs 2/20/4. If
you need to issue sleep() commands and it is locking the process
rather than the specific thread, maybe reduce that to 2/30-50/1?

Phillip B Oldham
ActivityHQ
[email protected] mailto:[email protected]


Policies

This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.

This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.

Well the simple answer is they dont, check you php-fpm settings (if
using dynamic process manager then threads = in use not spare etc)

On 27/09/2010 07:05, Ankur G. wrote:

I have a bunch of nginx and php-fpm worker threads. I am running a
very simple test with a script doing: <? sleep(20); ?>. I notice that
if I make two requests at the same time (from the same IP address), they
get serialized on the
php-fpm side and have a twenty second differential. Why would this
happen and the two requests not get processed in parallel when there
are an abundant number of threads?

This is a feature of PHP.

It carefully sequences the accesses so that only one thread at a time
can access the session variables.

You can call session_write_close() after you have updated all your
session variables, to tell php you are done with the session and it will
release any waiting thread.

If nginx is serving static content, these serves will not be effected.

Regards

Ian

Ian, nice pickup never conidered session locking.

Another soln, dont start a session on the blocking page if it is not
needed.

Sent from my iPod