Latest Status

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

Average rating
(0 votes)
Brashquido's picture

Location: Melbourne, Australia

Joined: Sep 2003

Send PM

Brashquido said:

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.

SteveF's picture

Location: Fort Worth, Texas

Joined: Nov 2007

Send PM

SteveF said:

Yes, I found those articles.

I removed all the php4 files and installed MS FastCGI, php5.2.4, and eAccelerator. I tried to set up MS FastCGI to call php5isapi.dll but that didn't work. Tried php5ts.dll and that didn't work either. php-cgi.exe seems to play well but I don't have a clue if this is the correct config for best throughput.

The applications I'm writing are simple sign-ups for university events. Students sign up for tests and labs in small groups spread across days and times. There are some days and times that all students prefer, and some undesirable; like Monday after a three day weekend. It's very competitive. The sign-up opens at a stated time and I end up with 150-200 students hitting the web site during the minutes leading up to the application accepting registrations. I have been getting overloads even before the sign-up starts, with students waiting minutes for the first page to show (this is with existing un-tuned application written with a perl cgi.exe frontend and an older database (IBI Focus) backend on a database server; two-tier).

The front end server is a Compaq ML530 with 2 2ghz xeon cpu's, 4gb memory, and 5 disk RAID of u320 SCSI. The backend is Compaq DL360 w/2 2.8ghz xeon cpu's, 4gm memory and two RAID 1+0 u320's.

I recently received two DL360G5 with 2 3ghz dual cpu's (12ghz eff.), 4gig memory, and 4 SAS 15k in RAID 1+0. I intended to set up two-tier but if the web server efficiency improves with the php described above, I would run both the web server and sql2000 database on the same server; or not depending on how my application runs under heavy load.

I appreciate any experience and advice you are able to share. In return, I would be glad to help with iis-aid testing, docs, etc.. as well as sharing results of server load statistics with actual usage of the application environment I described.

Steve

Brashquido's picture

Location: Melbourne, Australia

Joined: Sep 2003

Send PM

Brashquido said:

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.

SteveF's picture

Location: Fort Worth, Texas

Joined: Nov 2007

Send PM

SteveF said:

Would you double check me on my two configuration options:

ISAPI/eAccelerator

IIS6 Application extension .php set to c:\php\php5isapi.dll

and in c:\php\php.ini I have:

[eAccelerator]
extension="eaccelerator0952_5.2.4.dll"

FastCGI/eAccelerator

IIS6 Application extension .php set to C:\WINDOWS\system32\inetsrv\fcgiext.dll

in fcgiext.ini I have:

[PHP]
ExePath=c:\php\php-cgi.exe

and in c:\php\php.ini I have:

[eAccelerator]
extension="eaccelerator0952_5.2.4.dll"

Both of these configurations returned the phpinfo() result.

Is it correct to use only php-cgi.exe with MS FastCGI?

Also, my databases are small and highly volatile. I didn't think memcache would help because the database engine should cache and handle transaction coordination of updates better than memcache (I would think; I haven't done any research yet). Should I seriously look at memcache where the table has equal number of queries and insert/updates occurring?

Thanks, Steve

Brashquido's picture

Location: Melbourne, Australia

Joined: Sep 2003

Send PM

Brashquido said:

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.

SteveF's picture

Location: Fort Worth, Texas

Joined: Nov 2007

Send PM

SteveF said:

The applications are developed in-house. I'm not aware of commercial or open source solutions. There may be sign-up functionality built into more complex scheduling apps, but we've found that a simple tool that works well and does the one thing it's designed to do well is much better than a feature rich app that is complex, hard to use, and contains many things we'll never use, etc..

I think I now have enough information and guidence for the next week or so to test some configurations. Thanks for the taking the time to write your articles and share your experiences. Feel free to contact me if you have questions or advice.

Steve

p.s. I just noticed a reference to MS FastCGI and PHP non-thread safe version (Zend improvements for MS FastCGI). I installed PHP thread safe and am using php-cgi.exe from the thread safe version. Should I switch to PHP non-thread safe when MS FastCGI is configured? Can I have both versions of PHP installed at the same time (only one of them active at a time)? And does it matter since I want to use eAccelerator do I have to run PHP thread safe?

Brashquido's picture

Location: Melbourne, Australia

Joined: Sep 2003

Send PM

Brashquido said:

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.