Has anyone seen this issue (maybe not exact but similar that may have some insight)?
Before I describe it, Starters: My environment is Server 2012 R2 IIS8 64 Bit, running php version 5.3.28 NTS VC9 along with Railo 4 and tons of resources (2 quad cores/2.86ghz and 64 gigs/mem)
I have a php script that reads in a 2meg file and loops thru it, reading in line by line. On each line it calls a coldfusion file which in turn updates the db (the calls to CF is clocking in in the 2-5ms range. During the loop process, it goes painfully
slow where IIS thinks it is taking 1000ms (verified in the IIS logs under time taken). If left untouched, the process takes over an hour and never finishes.
One would automatically think it is the PHP script or the CF files, but after days of tinkering I can say its not (I'm not a developer nor did I write the code; and I do wish it was the code as it would save me heartache of trying to fix the process)
If your familiar with running Railo on IIS, it uses a interpreter called Boncode, which I have boncode logging enabled so I can see each time the cf page is hit in real time, and watch the log file increment in size. Needless to say, I have all sorts of
logging going on in just about every imaginable module.
Now, here is where it gets interesting: If, while in the loop and it is going painfully slow, I go into fastgci in IIS, and change the Max. Instances from whatever number it is (lets say 1) and change it to an arbirtrary number (lets say 32), it immediately
kicks in and goes very fast (lightning fast, the way it should be). Almost like it unjars something within the fastcgi module.
What is even freakier, You can go from 32 to 0, 16 to 19, 0 to 1, does not matter; all that matters is that the number changes. And it does not matter at what point the processing is occurring. I can wait 10 seconds and change it, then it will go fast.
Or I can wait 5 minutes, change it and it will go fast.
Originally I thought it was because of wincache, but the issue is present with and without wincache enabled, and it is present across 5.2.x , 5.3.x, 5.5 and 5.6 versions of php.
I'm kind of at a loss of where to look at this point, so anything is on the table. Its clearly something with the FastCGI module on IIS8; if it wasn't then the max instance change would have no effect on the process, but it is the only thing that I can
change that will have any impact (immediate or latent).
What is even weirder, if I change it from 1 to 0 on the fly and the process ends properly; if I re-run the same exact process , using the same import file, within seconds and without changing anything, it is slow again. But if I change it from 0 to 1,
immediately it goes fast.
And yes, this script/functionality was working fine without issue under server 2003 for close to a decade; this was the last server in a very large migration, so please no jeers (-; ... I fact I can take the same exact php version (moving the entire php
folder with extensions and ini file, move it onto the old server), take the same exact php file and the files to be processed; run it on the older server (2003/IIS6), and it runs just fine.
Other info
=======
- Site running the php script is in its own app pool
- That app pool is configured to run 32 bit apps
- Can't run that app pool in classic mode because of railo.
- I tried putting the PHP page on its own non-railo site, created a new classic mode app pool, and it was still slow and followed the same "max instance" change
- There are no php errors being logged
- In the fastcgi mappings, I increased the max requests to 10000 and matched it with the env var PHP_FCGI_MAX_REQUESTS
- It is PHP version agnostic; tried 5.2, 5.3, 5.5, 5.6 (32 and 64 bit) , same results
No matter what combination I try, the one constant is still the same; change the max instances on the fly (no recycling of the app pool) and it magically starts going fast.
Thoughts and thanks in advance
Mike