+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Development Area (/forum-1.html)
+--- Forum: Suggestions (/forum-2.html)
+--- Thread: default number of php fcgi threads (/thread-8114.html)
default number of php fcgi threads - sseitz - 10-14-2009 09:12 AM
Hi there,
Recent ispCP Installations are using two PHP threads per Apache Thread by default.
Most - if not all - modern Webservers are using a Threaded Model these days. (debian's Apache2 ships with 25 Min and 75 Max threads configured per default)
These Models are optimized for a stringent workload at each thread. Now, if some fcgi/fastcgi/however itself binds more than one thread to each webserver thread, the effects are measurable:
- suboptimal performance
a) at webserver level
b) at CPU level (instead you've got _lots_ of spare cores)
- waste of memory
Since most fcgi/fastcgi wrapped processes are consuming only fractions of seconds of cpu the loss of performance is only noticable on heavy loaded machines. This count's only if NO SINGLE userspace runs riot. As an example, assume some bad performing and ignorant php application (there are lot's of them available) hits it's configured max_execution_time of 120 seconds. It's easy to imagine what happens if this application is visited by some greater audience (say: 60 siminltanous users):
- The webserver spawns 60 threads
- fcgi spawns 60*2 threads
If every of the given users clicks the "run out of execution time link" only once an hour, every minute one php thread stalles. It's assumed to get kicked, but the fcgi pipeline lost it's interest after about 40-60 seconds of silence - say this happens for every second rioting php. The webserver serves some 500 Internal Error for this thread but keeps the thread up until timeout (which is configured by default to 300 seconds).
Summary after 10 minutes:
60 working webserver threads
120 working php threads
20 stalled php-cgi threads
10 stalled webserver thread
The example is calculated for only ONE application. Most servers I know are running 200 to 1000 users/domains.
As sead earlier, the problem is not CPU. Stalled processes are not taking any CPU. But they take their configured memory.
Taking a look at the memory footprint shows:
a running webserver thread takes about 12MB at minimum reserved
a stalled webserver thread takes about 9MB (i don't know what is free()'d but these values are taken from a live server)
a running php-cgi thread (debian standard ispCP defaults) takes appx., 12MB reserved
a stalled php-cgi the same.
This results in:
60x12MB apache threads 720MB
10x9MB stalled apache 90MB
120x12MB php-cgi 1440MB
10x12MB stalled php-cgi 120MB
Ignoring other tasks, like mySQL or proftpd, this single php app is responsible for
2160MB running, and
210MB waste (this is appx 10 Percent)
With a one-to-one mapping of fcgi pipelines, the results are much lower:
720MB apache as before
720MB php-cgi (60 instead of 120)
only 1440MB are used. Indeed, there are also stalled processes. To avoid this completely, the different timeouts of apache, fcgi and php should be synchronized.
@dev team: would you please change PHP_FCGI_CHILDREN to 1 ?