Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The production server runs a PHP application on IIS 6.0. During the peak hours we have had a few issues where the php-cgi.exe processes increase in numbers and approach around 200. The server comes to a crawl and we have to restart the server a multiple times to restore the normal behavior. When the server is running normally, I have noticed that there are only 10-15 php-cgi.exe processes in the task manager.

What could be causing the php-cgi.exe processes to increase in number from 10-15 to around 200 during the peak hours? Where should I look for a cause?

share|improve this question
    
Look at what those .exes are handling. Are they idle? probably stuck waiting for a resource. Are they at 100%? infinite loop, etc... –  Marc B Oct 19 '11 at 15:33
    
When I turn on the "CPU time" in the task manager for the processes, I can see some processes showing over 4 minutes. Is this normal? I have not seen anything running on the site for that long. We do not have any long running processes in the application. (Some background - The sole php developer in our team quit a month ago and this project fell into my lap. I am a .NET developer and PHP is not my expertise. I am trying to figure this out as much as I can. ) Is there any logging or tracing that PHP does that I can leverage for this? –  HYP Oct 19 '11 at 16:00
    
depends on if php-cgi sticks around and services multiple requests or not. if it's a single request, then 4 minutes of cpu is excessive. if it handles multiple requests, then 4 minutes is probably reasonable. I've never used PHP on windows, so don't know if IIS or php will keep a 'pool' of instances available or if they do a start up/service request/shutdown for every request. –  Marc B Oct 19 '11 at 16:02
add comment

migrated from stackoverflow.com Oct 20 '11 at 2:11

This question came from our site for professional and enthusiast programmers.

4 Answers

IIS6 CGI is typically 1 request -> 1 process. 15 concurrent PHP-CGI processes is likely due to 15 concurrent PHP-CGI requests. Or you've got a high hang-rate for the PHP processes, and they're just not exiting properly.

On Windows, process startup isn't as cheap as on *nix (I'm told); Windows threads are lightweight and can be simply spun up within processes, but starting a process is expensive.

Starting a new process for each incoming request can range from "expensive" to "disastrous". It could simply be that your load is increased when you see 200 concurrent processes - i.e. you have 200 outstanding requests "in flight". At some point, performance will drop to where new work is coming in faster than the old work can possibly be completed, and if you're restarting the server to cope with that, you're just punishing the users. Who may well make another request straight away to retry it.

If your processes are loitering, your app might have a hanging bug too. But that's by the by.

Anyhoo, this is all a long-winded way of getting to: Have you tried FastCGI? http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/

FastCGI on IIS allows reuse of an existing pool of non-exiting processes, so instead of one request starting, processing, and exiting a new process, each request is distributed to a pool of worker processes running (in this case) PHP-CGI.

Each PHP-CGI instance is kept alive while 1000+ requests are pumped through it, and then it's allowed to quit, and a new one is started in its place. From memory, there's a group of processes that do this concurrently to handle simultaneous requests (could be 4, 5 or 10 by default, configurable), and the performance should be (much) better.

share|improve this answer
add comment

It will execute once for each script that needs to run. It's peak hours... these are users on your site.

Optimize your scripts to take care of this.

share|improve this answer
add comment

It is all based on bandwidth.

Each connection creates a new instance of php-cgi.exe

So more users = more instances of php-cgi.exe

share|improve this answer
    
I doubt bandwidth has anything to do with this. When PHP is done executing, it will go to the server's buffer for sending to the client, yes? –  Brad Oct 19 '11 at 15:34
    
@Brad by bandwidth i mean number of users increased. –  Neal Oct 19 '11 at 15:35
add comment

You really should not be using IIS6 with PHP, it's not very well supported. Consider switching to IIS 7.5.

Because processes (vs threads) are resource intensive, your system is taking up all the available RAM when you have 200 php-cgi processes running.

Try setting maxInstances to 10 * the number of CPU processors you have.

This limits the amount of CGI processes that can be spinned up.

Also, as an alternative to IIS with PHP which is purely CGI based, you can use a WAMP package that uses PHP as an Apache module (thread based). This will greatly reduce the resources taken and can generally handle more connections. I use one called WampDeveloper Pro which is production ready and supported. There is also XAMPP and WAMPServer that are free but might not be the best thing to have in a production environment.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.