The IIS FastCGI preview is ready! I spent the last month developing the IIS 7 FastCGI module. Wade has adapted the module to work as an ISAPI on IIS 6 (and unofficially on IIS 5). Marchel and Mukhtar (and recently Cip) have been testing until late in the evenings for the last few weeks. Bill and Mike have been managing the project. It was really exciting going from nothing to something in 1 month. Normally we take product development at a slower pace.
Thank you to these excellent PHP developers: Dmitry, Wez, Andi and Stanislav. I'm guessing most of them are currently at the San Jose Zend/PHP Conference
I don't know what throughput numbers will be officially recorded, but unofficial ones I've tested (helloworld.php, Longhorn Server, pre-release PHP bits) are running 25x (twenty-five TIMES) faster than running PHP as a CGI. So this is a real win for people who cannot run PHP as an ISAPI. (Some PHP extensions are not thread safe and therefore couldn't be run safely as ISAPIs. I don't know which ones, just have nasty stories from Andreas in CSS)
Technology Preview 1 is be available on www.iis.net. So far I've only tested it with PHP and the libfcgi SDK sample echo.exe. I'd love us to try out some other technologies, so if you have any suggestions please comment on the FastCGI forums. If you find any FastCGI apps we're incompatible with, please bring it to our attention and we'll get them working!
Overview of the current design (which could change substantially before release):
- Configuration applies at the worker process level
- Each worker process can be configured to run many FastCGI process pools
- Each process pool can be configured independently
- Processes are spawned on demand up to the maximum (there is no MinServers setting)
- If there are more requests than processes, requests are queued up to request limits
- If a FastCGI process has been idle for more than 5 minutes we retire it
IIS 7 configuration settings (per process pool):
- fullPath: path to application for this pool (e.g. d:\php\php-cgi.exe, NOTE: must match handlers section)
- maxInstances: maximum number of processes to create in this pool
- instanceTimeout: maximum duration a request can last
- instanceMaxRequests: process will be retired after exceeding this number of requests
- protocol: use named pipes or tcp. The tech preview currently only supports named pipes, but TCP should be simple to add.
- queueLength: maximum number of requests to queue (when this is exceeded the module will start 500'ing)
- flushNamedPipe: Flush the named pipe at the end of each request. This is to workaround, what seems to be a bug in libfcgi: if two FastCGI requests arrive in a single ReadFile call, libfcgi closes the pipe. (If anyone wants to tackle this problem, I'd be happy to provide a repro)
Links:
Comments