Using Wincache and Application Warm-Up together can allow you to create a cache for your PHP web applications before any request arrives. This will enable you to not only have scheduled server recycles without any downtime, but will also save you the initial compilation time of the first requests to a webpage.

It should be noted that Application Warm-Up is only available for Windows Server 2008 R2. You can use the Web Platform Installer to install everything in this post – Wincache, Application Warm-Up, PHP, and the web applications.

For this post, I will be using Acquia Drupal, Gallery2, and Wordpress for examples. After installing and performing the initial setup phases of the web applications, the first step is to enable Application Warm-Up’s ability to start the application pool when the service is started. This is done in the site(s) that contain your web applications.


The next step is to add the relative URI paths to the web pages that need to be cached. Typically, this should include the most frequently hit or most computationally intensive pages. For Acquia Drupal and Wordpress, this means adding warm-up requests for /index.php. For Gallery2, the page most frequently viewed is typically /main.php.

To do this, navigate to the site or the application that contains your web application, and click Application Warm-Up. Clicking Add Request… will lead you to a dialog box where you can add the URI.



The same should be done for your other sites (in my case, Acquia Drupal and Gallery).


image You can test out the settings by doing a quick iisreset and then navigating to wincache.php (which can be found in %programfiles(x86)%\iis\windows cache for php) to check out the results.



You can also take advantage of this by having scheduled recycles that can be found in the application pool that contains your web sites. When the recycle takes place, Application Warm-Up will keep old worker processes active while the recycle is taking place so that no downtime occurs. Furthermore, the new worker processes will already have the cached pages ready to go for the new requests.


Hope this helps!

When deploying PHP web applications that handle their errors with their own error pages, the existingResponse for Custom Error Pages feature of IIS should be set to “PassThrough” for that particular site. This greatly improves the customer experience when accessing your new application, particularly if your custom error pages are merely the defaults that come with IIS.

Custom Error Pages set to “Auto” (the default):


Custom Error Pages set to “PassThrough”:


This property can be set for either the site in particular or the server as a whole. To set it for the server, using appcmd.exe (found in %windir%\system32\inetsrv), the command is

appcmd.exe set config -section:system.webServer/httpErrors /existingResponse:"PassThrough" /commit:apphost

However, you can also do this on a per site, application, or virtual directory basis as well. Using appcmd, use the following command:

appcmd.exe set config "Default Web Site/application" -section:system.webServer/httpErrors /existingResponse:"PassThrough"

Replace “Default Web Site/application” with the actual path to your desired location to change.

You can also do this by editing (and creating if needed) a web.config file in the actual folder of the location, which would look something like this:

<?xml version="1.0" encoding="UTF-8"?>
        <httpErrors existingResponse="PassThrough" />

And voila, you’re done!

With the imminent release of Windows 7 and Server 2008 R2 to the general public, some of you may want to automate the installation FTP 7.5 on the machine. Thanks to pkgmgr, this is made amazingly simple!
To install both the UI and the FTP service, simply run the following command in an elevated cmd shell:

cmd /c "pkgmgr /iu:IIS-FTPSvc;IIS-FTPExtensibility” 

However, for a more lightweight installation where you just want to install the service, this is possible via:

cmd /c "pkgmgr /iu:IIS-FTPSvc” 

On this line of thinking about automating simple and common tasks, here’s a simple batch script that sets up a basic ftp site on port 21 with a data directory at C:\inetpub\ftproot (can be a different drive depending on system) and allows read/write access to all users who already have access to the would-be server. NOTE: NO FURTHER SECURITY IS IN PLACE.

You can copy and paste this directly into an elevated cmd shell window or make a batch file out of it to distribute it across multiple machines or change the values of the variables (ftproot and ftpsite).

cd %windir%\system32\inetsrv 
REM ftproot is the location of the ftp data directory 
set ftproot=%systemdrive%\inetpub\ftproot 
REM ftpsite is the name of the ftp site 
set ftpsite="ftp site" 
if not exist “%ftproot%” (mkdir "%ftproot%") 
cacls "%ftproot%" /G IUSR:W /T /E 
appcmd add site /name:%ftpsite% /bindings:ftp://*:21 /physicalpath:"%ftproot%" 
appcmd set config -section:system.applicationHost/sites /[name='%ftpsite%']"SslAllow" 
appcmd set config -section:system.applicationHost/sites /[name='%ftpsite%']"SslAllow" 
appcmd set config -section:system.applicationHost/sites /[name='%ftpsite%'] 
appcmd set config %ftpsite% /section:system.ftpserver/security/authorization /+[accessType='Allow',permissions='Read,Write',roles='',users='*'] /commit:apphost 

The site created allows any user that has access to the machine to login remotely with his Windows credentials. He also has both read and write access to the folder (ftproot). The site does block against anonymous user logins, though. Furthermore, while SSL is allowed, it is not required, meaning clients are not required to connect over an encrypted channel.

More Posts