Kanwaljeet Singla's Blog

IIS team recently released FastCGI ISAPI 1.5 for IIS 5.1 and IIS 6.0. One of the major new features added in this release is per application process pools. Per application process pools allow users to specify a unique FastCGI mapping for a particular web application in fcgiext.ini. Using this functionality administrators can now choose to run a web application with PHP version which can be different from what is used for rest of the PHP applications in the same site or the server. This was always possible in IIS 7.0 and 7.5 by overriding PHP handler in web.config but not on WinXP and Win2K3. Version 1.0 of FastCGI ISAPI only allowed specifying a different process pool at a site level granularity. Read more ...

View the original post

Many customers running WinCache reported seeing different cache statistics on consecutive requests to wincache.php. Specifically, cache uptime and opcode cache summary returned second time by wincache.php was completely different than the data returned first time. Occasionally data shown in the opcode cache summary table didn’t match the chart displayed on its side. Many customers correctly guessed that this happens because there are multiple cache instances present in different php-cgi processes but thought that none of the PHP processes are sharing cache data and were worried about excessive memory usage by WinCache. I have been replying to many customers personally and posting on forums explaining why they see this behavior but as more and more customers are using WinCache, this question is becoming more common. Read more ...

View the original post

In addition to FastCGI migration provider, MSDeploy 1.0 RTW shipped with a URLScan to request filtering migration provider to ease migration of UrlScan.ini settings to system.webServer/security/requestFiltering section. Even though URLScan 3.1 is supported on Win2K8 and you are not required to move to request filtering module, there are few advantages in using request filtering module. One advantage is that all your configuration can stay together in applicationHost.config and web.config and you are not required to maintain a separate configuration file. Another advantage is that you can take advantages of new configuration system features like distributed configuration, shared configuration, locking, ability to use appcmd, UI, configuration editor etc which cannot be used if you use UrlScan and your configuration is in UrlScan.ini. Read more ...

View the original post

We are seeing huge momentum behind adoption of WinCache. In the month of September, WinCache v1 Beta was downloaded more than 13,000 times making it one of the most downloaded IIS extensions in the first month following its release. Many happy customers chose to run it on their production servers despite its beta tag. We got very encouraging feedback from the beta release and we are pushing hard for our next release. Our next release date is approaching fast and I wanted to give an update on new features and bug fixes. If your favorite feature was missing in the beta and is also not in the list below, please email me or post on the forums so that we can consider it for future releases of WinCache. Read more ...

View the original post

Problem
As you know FastCGI functionality on IIS 5.1 and IIS 6.0 is provided by FastCGI ISAPI extension which is available as an independent download. On IIS 7.0 and beyond, FastCGI functionality is provided by IIS FastCGI module which comes with the operating system. These components use different configuration stores to store the settings that affect their behavior. FastCGI ISAPI uses an INI file named fcgiext.ini as its configuration store whereas FastCGI module keeps configuration in applicationHost.config in xml format with rest of IIS configuration. Before, migrating from IIS6 to IIS7 involved migrating fcgiext.ini configuration to FastCGI module manually as there was no automated way to do that. MSDeploy only had functionality to migrate metabase configuration but because FastCGI ISAPI configuration is kept separately in an INI file, that wasn’t possible. Read more ...

View the original post

Why WinCache?
Use of PHP accelerators is very common to make PHP run faster. Most of the existing PHP accelerators which are in use today are designed keeping *nix architecture in mind and mostly doesn’t work well on Windows. For example, APC which is very commonly used on *nix doesn’t work on Windows. Xcache does work in ISAPI mode but crashes when PHP is running in FastCGI mode with multiple php processes alive. Absence of a stable PHP accelerator on Windows made people complain about PHP performance on Windows all the time. Another complaint which we heard consistently from customers running PHP on windows was that file operations on Windows were slower than on *nix. Reason being Windows’s CreateFile system call which is much more expensive than a fopen call on *nix as CreateFile goes through a much more complex security check involving ACLs. Read more ...

View the original post

View the original post

IIS team today released FastCGI ISAPI 1.5 Beta for WinXP and Win2K3 which has some very nice additions to existing FastCGI ISAPI functionality. Following additions have been made to FastCGI ISAPI 1.0.

1. Few features we added to FastCGI module in IIS 7.5 have been added to FastCGI ISAPI 1.5 as well. These include MonitorChangesTo, StderrMode and Real-time tuning. Read more about these here.

2. Few customers complained about IIS terminating the FastCGI processes abruptly (on running into IdleTimeout, InstanceMax etc) without giving them a chance to run cleanup code in the FastCGI application.  Read more ...

View the original post