Partner and Community Forums
IIS 6 + PHP Performance Issues
Last post Jun 11, 2008 11:17 AM by brashquido
Dec 07, 2007 10:32 AM|cwalker3|LINK
I work for a company that has a vBulletin board served up using PHP and mySQL. Nothing else but the board is on the server.
We run 2003 Server SP2. Our box has (8) 3.0 GHz CPU's, and 2 GB of RAM.
PHP version 5.2.1 is running. More configuration details can be found here:
Under normal load we have about 300 users browsing our boards. Under 'peak' load, we can only handle about 500 users. Our user base would probably allow us to get 2000 or more concurrent users at a time, but our server is holding us back.
Under peak load, The IIS process is using about 15% of CPU, and about 450,000 MB of RAM. There is always 1GB or more of free memory available. Disk I/O is fine per Performance Manager.
My MySql database is also fine.
During peak load, the site becomes unresponsive. Clicks take two minutes or more.
I can isolate the problem to IIS/PHP because I've set up a mirror site on the same box. The mirror performs fine under load, so I can confidently rule out disk I/O and database performance problems.
Does anyone have any suggestions with regard to PHP/IIS optimization? I'm at a loss as to why the site stumbles when I have so much headroom in terms of resources available...
Dec 07, 2007 12:18 PM|rickjames|LINK
I'd try the following:
- Use FastCGI: it is generally more reliable than ISAPI for hosting PHP apps (link: iis.net/php) (Since you have an 8P, you may want to test increasing MaxInstances=8, default is 4)
- Use a newer version of PHP: The IIS team and people on these forums have found a number of bugs in PHP that are fixed in newer versions
Dec 07, 2007 12:24 PM|cwalker3|LINK
Actually I've tried to get FastCGI up and running to no avail. I really want to check it out too.
I'm having some sort of PHP redirect issue with FastCGI. Basically the vBulletin code is having problems after you hit sumbit on posts. Instead of redirecting as expected, it dies and serves a blank page. No one has been able to help me on that one either
Outside of the redirect, everything else with FastCGI worked great.
Dec 07, 2007 12:45 PM|rickjames|LINK
Which version of FastCGI did you encounter these troubles on?
There were some redirect bugs in the GoLive version of FastCGI. These are fixed in the released version.
Dec 07, 2007 03:00 PM|cwalker3|LINK
Dec 07, 2007 09:42 PM|brashquido|LINK
I agree with Rick in that with an 8 CPU system you should see better performance using FastCGI with the MaxInstance value set to 8. However I don't necessarily believe it is a PHP/IIS issue that is causing your performance issues, and at face value I would
suspect that it is a MySQL causing your contention issue. Just because you are seeing no I/O bottlenecks doesn't necessarily mean there are no database performance problems.
A few questions for you regarding your MySQL environment;
1) Why are you using MySQL 5.1? 5.1 is a release candidate, and may still have serious unresolved/unknown bugs.
2) What storage engine are you using for your database? Myisam or InnoDB?
3) If you start a MySQL command prompt, what do you get when you run this command:
SHOW STATUS LIKE 'TABLE%';
4) Have you tried enabling your slow query log? If so, have you found any pattern to the query types that are taking a long time to execute?
Dec 07, 2007 11:06 PM|cwalker3|LINK
you should see better performance using FastCGI
I would love to try it, but for some reason I'm having redirect issues after form POSTS. My redirects die and I get a blank page. I've followed the instructions on this site to the letter.
Why are you using MySQL 5.1?
It came with the house, so to speak.
What storage engine are you using for your database? Myisam or InnoDB?
what do you get when you run this command:
That's after about 4 days.
My query cache runs at about 60%, and my key efficiency is almost always at 100%.
Have you tried enabling your slow query log?
I'll give it a shot.
I'm really confident that my database is fine.
First off, it's very small database - about 200MB.
Second, and this is the kicker - I've created a mirror site on the same box. It's the same in every way, and it hits the same DB. Under load when my prod site is unresponsive, I can flip to the mirror and get instantaneous response rates. In fact we've
resorted to giving out the URL to the mirror to a few important people, and everyone gets fantastic response time.
Dec 07, 2007 11:15 PM|cwalker3|LINK
Let me throw something out there, and see what you guys think.
This site also hosts an ASP 3.0 site, which serves up content via an Access DB. Stop laughing, really. Again, this 'came with the house'. This is a new client of mine and I can only fix so much at the outset...
The ASP site is the gateway site and home site, and the boards are linked to from there. Most of our user's more than likely hit the boards via a direct link and bypass the home site. If people try to hit the home page though, multiple Access queries are
fired by ASP and pages are built dynamically.
I'm wondering if Access is the bottleneck, specifically the connections to the DB. I would figure though that the IIS process is smart enough to delegate those processes and waits separately from anything being done with the PHP pages.
I created a new Site and Application Pool today, and we're going to move the boards there. This way the PHP site will have it's own URL and memory space, and the ASP site will as well. Since we have plenty of headroom on the server in terms of resources,
I'm hoping the PHP site will get healthier without having to battle the ASP site, and I don't really care about the ASP site.
I'm trying this anyway, but we are testing the new site, making sure everything works OK. I'd feel better though in the meantime if someone said "OMG that *HAD* to have been the problem!"
Dec 09, 2007 05:52 PM|brashquido|LINK
As a rule of thumb using InnoDB is a better option for forum style applications that are heavy on database writes as InnoDB is capable of row level locking for updates/inserts where MyISAM has to lock the entire table. That said your table_locks_waited
value doesn't seem especially high to me considering the traffic. Will be interesting to see what your slow query log shows. Might also be worth turning on the "log queries not using indexes" option so that you can see what queries are not optimized.
Sounds like it might be best to wait on the FastCGI front and stick with ISAPI for the minute. I've seen similar FastCGI issues to what you described, but haven't had the time to investigate them myself either. Other things you could try from here are to
use an opcode cache such as eAccelerator, implement Memcache (providing your site gets significant reads) and use the xdebug tool to do some profiling on your scripts to see where the time expensive code is.
Dec 10, 2007 08:40 AM|cwalker3|LINK
The nature of my forum makes it more read heavy than write heavy. A large part of our population lurks. Basically sports insiders post transaction tidbits, word spreads, and the site gets hammered by people looking for info.
My slow query log has three hits in there. They are three run of the mill queries that took 15 seconds or less each. The catch is that all three were executed between 2:30 and 2:40 AM on Friday, which is when my backup was running.
I am *very* confident that my database is in tip top shape.
Pages that aren't even hitting the database will take two minutes to load under heavy traffic.
Dec 10, 2007 09:46 AM|brashquido|LINK
Yep, I agree. If you have nothing in the slow query log then it won't be a MySQL contention issue. In that case I suggest you have a look at eAccelerator and Memcached as you have plenty of RAM to spare. Also, I don't suppose you have monitored your bandwidth
to see if there is a bottle neck there at all during peak times? I doubt this though seeing as you've tested with a mirror site on the same server.
Dec 10, 2007 09:53 AM|cwalker3|LINK
brashquido, I really appreciate you reading and responding... I will research the tools you recommended.
I have monitored bandwidth, and the pipes are wide open during peak times.
Dec 10, 2007 10:40 AM|brashquido|LINK
No problem. The tools I mentioned should go a long way to helping performance, but ultimately there is only so much they can do. You may still need to do some script profiling using xDebug to really nail down where the bottleneck is.
Dec 12, 2007 12:05 AM|cwalker3|LINK
All, I think I've figured this out. Bear with my ignorance, as I don't portend to be anything near an IIS wiz.
First, we've moved the ASP/MS Access based content portion of our site to it's own application in IIS.
Second - and this is pretty exciting - I upped our worker threads for our message boards from 1 to 8 (we have 8 procs). Bingo! Finally the memory and CPU's start to actually get used. My queries per second in mySQL went from a prior max of 20/sec to 60+/sec.
So duh! Up your worker processes from the default to get more out of your PHP/IIS solutions!
Dec 12, 2007 06:17 AM|brashquido|LINK
Nice work. I was so focussed on PHP/MySQL myself I didn't think to step back and look at your IIS config. I would be very interested to hear site performance stats at peak times now after the changes.
Dec 12, 2007 01:41 PM|cwalker3|LINK
The timing of this couldn't have been better. A major transaction went down today, and our board was flooded with people wanting to talk about it.
We're running along smoothly with triple our typical heavy load (1000 users currently). mySQL peaked at 106 queries/second, and I still have CPU and memory to spare. Talk about a relief...
Dec 12, 2007 05:06 PM|brashquido|LINK
Jun 11, 2008 06:56 AM|canadaka|LINK
I thought i read somewhere that its not the best to use Web Gardens with IIS and PHP because of PHP's memory handling or something? Also something about PHP sessions can't transfer between gardens properly?
Have you experienced and problems running your sites app pool in a web garden?
Jun 11, 2008 11:17 AM|brashquido|LINK
I'd be interested in reading that if you were able to locate the source, however I've never had any issues using PHP ISAPI on IIS6 in a web garden. It is definately not a set and forget kind of option as there are some very real risks. The only memory issues
I've found you really need to be concious of is that your PHP memory consumption will increase by a factor of x, where x is the number of processes running in your web garden. For example if PHP is topping out at 128MB of ram on your server, and you configure
IIS to use a web garden with 4 worker processes then your memory consumption will now top out at around 512MB. This potentially could comsume all of your physical memory which would result in the use of virtual memory and page file thrashing.