Re: FastCGI + PHP + APC on Apache2 - Concurrency issues

"Ben Chabot" <[email protected]>
Newsgroups gmane.comp.web.fastcgi.devel
Message-ID <[email protected]>
Try "ab" Apache Benchmark. 

Example :

--- test.php ---

<?
print date("Y-m-d H:i:s"); print "<br />";
sleep(5);
print date("Y-m-d H:i:s"); print "<br />";
?>
--- END test.php ---

--- ab ---

# ab -n 3 -c 3 http://www.host.net/test.php
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.116 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.host.net (be patient).....done


Server Software:        Apache
Server Hostname:        www.host.net
Server Port:            80

Document Path:          /test.php
Document Length:        50 bytes

Concurrency Level:      3
Time taken for tests:   5.17623 seconds  <-- total time for the test.
Complete requests:      3
Failed requests:        0
Write errors:           0
Total transferred:      618 bytes
HTML transferred:       150 bytes
Requests per second:    0.60 [#/sec] (mean)
Time per request:       5017.623 [ms] (mean)
Time per request:       1672.541 [ms] (mean, across all concurrent requests)
Transfer rate:          0.00 [Kbytes/sec] received

--- END ab ---

ab -n 3 -c 3 should mean send 3 requests, 3 concurrently.  The time taken
for all 3 was 5 seconds, not 15.

If you use livehttpdheaders (firefox extension) and watch what your browser
is sending,  then telnet to your http port and send the same things, you'll
see it isn't like "open connection -> request page -> get result -> end"

It actually keeps the session open to remove the overhead of reconnecting
for every image and every little things, so it's "open connection ->
request page -> (wait 10 secs) get result -> ... wait for next request".

So really, it's a combination of things.  Your browser is using the same
connection to the same apache child, which won't accept the next request
until it has finished processing the first.

But FastCGI is dealing with the requests in a round robin fashion I expect.
 If you strace  one of them during your refreshes in your browser, you will
probably see it hit one of them only once.  Even though the connection
stays with the same apache child.  The child sends the request to the
fastcgi process manager, which does not care which running php process
processes the request.

So basically, although it seems like it's lagging, it's only lagging for
that single person who is trying to load a page 3 times in a row that takes
10 seconds to load. =)

Anyone : feel free to correct me if I am incorrect.

Hope that helps!
Ben

On 11:05:55 am 10/17/06 "Renaud Drousies" <[email protected]> wrote:
> Actually I am requesting the page 3 times in 3 different browser tabs
>
> On Mar 17 octobre 2006 16:36, Ben Chabot a écrit :
> >  What method are you using to execute the script three times?
> >
> >  Because, afaik, an apache child can only handle one request at a
> >  time.  So if it's using the same child (sort of like how
> >  keepalives work) and sending
> >  the same request to the same apache child, that would explain it, I
> >  believe.
> >
> >  On 9:36:22 am 10/17/06 "Renaud Drousies" <[email protected]>
> >>  wrote: Hello,
> >>
> >>  I am not sure this is actually a FastCGI, Apache2 or PHP
> >>  configuration issue, but here is my problem:
> >>
> >>  I have the current configuration in my apache2:
> >>
> >>  Alias /cgi-bin/ /www/cgi-bin/
> >>  FastCgiServer /www/cgi-bin/php-fcgi -processes 1 -idle-timeout 180
> >>  -socket /tmp/fastcgi.socket
> >>  AddType application/x-httpd-fastphp .php
> >>  Action application/x-httpd-fastphp /cgi-bin/php-fcgi
> >>
> >>  And that wrapper:
> >>
> >>  #!/bin/sh
> >>  PHP_FCGI_CHILDREN=4
> >>  export PHP_FCGI_CHILDREN
> >>  PHP_FCGI_MAX_REQUESTS=500
> >>  export PHP_FCGI_MAX_REQUESTS
> >>  exec /usr/local/bin/php
> >>
> >>
> >>  When I start apache, this gives me the correct number of
> >> processes:
> >>  www-data  3422  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/fcgi-pm -k start -DSSL
> >>  www-data  3423  3422  0 04:59 ?        00:00:00  |   \_
> >>  /usr/local/bin/php www-data  3424  3423  0 04:59 ?
> >>  00:00:00  | \_ /usr/local/bin/php
> >>  www-data  3425  3423  0 04:59 ?        00:00:00  |       \_
> >>  /usr/local/bin/php
> >>  www-data  3426  3423  0 04:59 ?        00:00:00  |       \_
> >>  /usr/local/bin/php
> >>  www-data  3427  3423  0 04:59 ?        00:00:00  |       \_
> >>  /usr/local/bin/php
> >>  www-data  3428  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>  www-data  3429  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>  www-data  3430  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>  www-data  3431  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>  www-data  3432  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>  www-data  3434  3421  0 04:59 ?        00:00:00  \_
> >>  /usr/sbin/apache2 -k start -DSSL
> >>
> >>
> >>  I am using only 1 FastCgiServer process because it is required to
> >>  benefit from the APC cache between the different php handlers. The
> >>  problem is that I cannot seem to handle more than 1 php request
> >>  at a time.
> >>
> >>  This is a script I am using to test that:
> >>
> >>  print date("Y-m-d H:i:s"); print "<br />";
> >>  sleep(10);
> >>  print date("Y-m-d H:i:s"); print "<br />";
> >>
> >>  If I request that script 3 times, within the same second, it
> >>  returns me:
> >>
> >>  2006-10-17 05:02:35
> >>  2006-10-17 05:02:45
> >>
> >>  2006-10-17 05:02:45
> >>  2006-10-17 05:02:55
> >>
> >>  2006-10-17 05:02:55
> >>  2006-10-17 05:03:05
> >>
> >>  It waits for the previous script to be done to start the next
> >>  request. Am I doing something wrong in my configuration? I would
> >>  expect my server to be able to handle more thant 1 request at a
> >>  time :-)
> >>
> >>  Actually this acts the same if I increase the FastCgiServer's
> >>  -process...
> >>
> >>  Thanks!
> >>
> >>  Regards,
> >>  Renaud
> >>
> >>
> >>
> >>  ___________________________________
> >>  fastcgi-developers mailing list
> >>  http://fastcgi.com/fastcgi-developers/
> >
> >  ___________________________________
> >  fastcgi-developers mailing list
> >  http://fastcgi.com/fastcgi-developers/
> >
>
>
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.