PHP Apache – Handle 1000 simultaneous request

apache-2.4php-fpm

Question moved from Stackoverflow

I have a PHP script which handles request from client.
I should be in a situation to handle 1000 concurrent requests (using apache benchmark). When I presently run apache benchmark with 300 concurrent requests, I am able to handle all the requests.But when I exceed the 300 mark, apache is not able to handle it.
(It exits with apr_socket_recv: Connection reset by peer (104) )

And this is the apache error log.

[Thu Oct 29 11:20:34.984542 2015] [mpm_prefork:notice] [pid 6244] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.13 configured -- resuming normal operations
[Thu Oct 29 11:20:34.984581 2015] [core:notice] [pid 6244] AH00094: Command line: '/usr/sbin/apache2'
[Thu Oct 29 11:21:38.638943 2015] [mpm_prefork:error] [pid 6244] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

This is the mpm prefork config –

<IfModule mpm_prefork_module>
    StartServers              8
    MinSpareServers           5
    MaxSpareServers          20
    MaxRequestWorkers        256
    MaxConnectionsPerChild   4
</IfModule>

From the above config, I could handle 256 * 4 > 1000 requests concurrently. I am presently using a 8 core machine with 16GB of RAM.

Is it possible for my apache server to handle 1000 concurrent requests?

More Details on what my PHP code Does

On receiving the client request, my php script in turn starts a python script. This python script, telnets into 50 different machines in parallel using the python multiprocessing. On an average , it takes 0.5 seconds to complete one request.

EDIT

As per the suggestion of shodanshok.I changed the mpm worker conf file to this:-

   <IfModule mpm_prefork_module>
        ServerLimit              300
        StartServers              50
        MinSpareServers           5
        MaxSpareServers          10
        MaxRequestWorkers        300
        MaxConnectionsPerChild   0 
   </IfModule>

But the benchmarking still does not complete, it exits very early . And this is what i found on the apache logs.

[Thu Oct 29 12:14:42.372184 2015] [mpm_prefork:notice] [pid 29261] AH00169: caught SIGTERM, shutting down
[Thu Oct 29 12:14:42.913499 2015] [mpm_prefork:notice] [pid 1397] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.13 configured -- resuming normal operations
[Thu Oct 29 12:14:42.913539 2015] [core:notice] [pid 1397] AH00094: Command line: '/usr/sbin/apache2'

Best Answer

You misunderstand what MaxRequestWorkers and MaxConnectionsPerChild do. From the manual page:

The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the MaxRequestWorkers limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced.

For non-threaded servers (i.e., prefork), MaxRequestWorkers translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.

For threaded and hybrid servers (e.g. event or worker) MaxRequestWorkers restricts the total number of threads that will be available to serve clients. For hybrid MPMs the default value is 16 (ServerLimit) multiplied by the value of 25 (ThreadsPerChild). Therefore, to increase MaxRequestWorkers to a value that requires more than 16 processes, you must also raise ServerLimit.

and

The MaxConnectionsPerChild directive sets the limit on the number of connections that an individual child server process will handle. After MaxConnectionsPerChild connections, the child process will die. If MaxConnectionsPerChild is 0, then the process will never expire.

In short, in prefork mode, MaxRequestWorkers is the total number of concurrent connection allowed. MaxConnectionsPerChild is here only to tell the child to die after so many connections.

In other words: raise your MaxRequestWorkers setting will solve your problem.