Hi Dominic,
I just used iis-aid version IIS-Aid_PHP_Installer-Beta_1.exe and it worked well. I installed on a fresh w2k3 sp2 but haven't tested yet.
I noticed that the installer still sets up session.save_handler as a path instead of 'files'. Also that APC may be unstable and should be disabled in php.ini.
I also read where you were testing eAccelerator and planed to include it.
I would like to set up my server to handle 300-500 concurrent requests and am a bit lost as to the best extension to use and insuring it works well with IIS6 application pools, fastcgi, etc.
Do you have a more current installer available? If not, do you have any advice where I can find good set up information to guide me?
Thanks, Steve
Hi Steve,
Yeah, the IIS Aid Installer still needs a bit of attention. I'm wanting to make the next release as complete as possible as it will be the last version I put out based on PHP4 as it is being dropped at the end of the year. With PHP 4 being at end of life in the next few months I would have to advise you to look at using PHP 5.2 unless you have a specific need for PHP4 (legacy code, etc). I do plan to build a new installer based on PHP 5.2.x, but that will be some time away yet as I simply don't have the free time at this end of the year.
300~500 concurrent requests is starting to get into pretty serious sort of performance territory, and will depend on the applications you are using. For PHP configuration though I recommend you have a look at the article I wrote recently on performance tuning php 5.2 on iis. My latest article on efficiency of the go live Microsoft fastcgi handler might also be of interest.
Hi Steve,
Sounds like you at least have some decent hardware up front to process your data, so getting PHP to work significantly better shouldn't be an issue. Using ISAPI or FastCGI with eAccelerator is going to be your best option, however which one is best for your application is going to require some stress testing. If possible I'd recommend keeping your web server and database server on different phyiscal machines to help reduce resource contention. I'd also recommend having a look at the xdebug tool to track down time/resource expensive code, and as you have plenty of RAM perhaps even look at using the memcache server to reduce database server load.
Those settings look good to me, and yes you are correct that only php-cgi.exe should be used with FastCGI. If your database is heavy on writes, then a database cache is not going to help a terrible lot. In this situation I'd definitely advise separating your web and database services onto different physical machines. Are these PHP applications developed in house, or are they an open source/commercial solution? Using FastCGI/eAccelerator and separating your DB and Web services onto separate machines will do a lot, but they can only do so much. Code optimization can gain you quite a bit of speed, so it might be worth looking into that. Using the xdebug tool can help you trace where the bottlenecks are here.
That's great Steve, I'll be interested to know how you get on. In my testing I've found the non thread safe version of PHP does offer a slight performance advantage over PHP, but as there are currently no open source non thread safe bytecode/opcode accelerators which are stable on IIS you get much better performance using the thread safe version of PHP with eAccelerator (which is stable) . Xcache and APC are available in both thread safe and non thread safe versions, but use the mmap memory management scheme which relies on their being one parent php-cgi.exe process with all other php-cgi.exe processes being created as child processes. PHP on IIS doesn't work like this as php-cgi.exe processes are created in parallel, hence the instability when using these bytecode/opcode accelerators.
Location: Melbourne, Australia
Joined: Sep 2003