3

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?

Marcel Janus
  • 1,115
  • 2
  • 14
  • 29
  • 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? –  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
  • How do you know whether php-cgi is servicing multiple requests or not? – luisdev Aug 23 '18 at 09:46

4 Answers4

4

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.

TristanK
  • 9,073
  • 2
  • 28
  • 39
1

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

Naftali
  • 111
  • 3
  • 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. – Naftali Oct 19 '11 at 15:35
1

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.

rightstuff
  • 630
  • 1
  • 5
  • 6
  • Why do you recommend setting maxInstances to 10 * the number of CPU processors you have? Why 10x? – luisdev Jun 13 '18 at 08:39
0

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.

Brad
  • 1,419
  • 22
  • 43