Work items collected from Tek-X

Last week I was in Chicago in the company of very passionate and smart PHP programmers at Tek-X. I got to meet some well-known members of PHP community and also fellow Microsoft employees who have been working on improving PHP experience of Windows. I would admit that meeting people was the best part of Tek-X for me. Sessions were great too and I learnt a great deal from them. I returned to Seattle more knowledgeable and passionate for PHP then ever. One of the things I wanted to get from Tek-X was a list of problems PHP users face on Windows so that we can work on solving them. Below is the list of work items I collected during informal discussions, questions during my talk and from other sessions.
1.       PHP 5.3 in WebPI
Today, Web Platform Installer (WebPI) only offers latest version of PHP 5.2. Folks want us to offer PHP 5.3 through WebPI. We receivedthis request during web developer summit and work for this is already in progress.
2.       PECL extensions in WebPI
There are few PECL extensions which are very popular (e.g. XDebug, uploadprogress) and people want us make them available in WebPI.
3.       WebPI to download PHP from
During my WebPI demo, Derick Rethans pointed out that we are downloading PHP from http://sourceforge and not We used to install PHP from but moved recently to sourceforge when went down for maintenance. We will move back to once it has mirrors set.
4.       SQL driver for PHP extension on PECL
PHP community is very happy with the fact that WinCache source code is in PECL repository and documentation is exclusively available on They want SQL driver for PHP extension to move from codeplex to PECL. Even better will be moving related documentation from to as well.
5.       PHP frameworks in WebPI
During my talk, people asked if there are any plans to add popular PHP frameworks like CakePHP and Zend Framework in WebPI. If a PHP application code already has framework code included, WebPI will just copy that as part of application install. Right now there are no plans to offer standalone PHP frameworks from WebPI. I will be discussing with the product team and see if this makes sense for us.
6.       Simplify setting up of PHP build environment on Windows
Many at Tek-X made fun of the fact that compiling PHP on Windows is incredibly hard. I have published a script (winbuild.bat) which makes this very easy. I will continue to produce documentation/scripts related to this unless building PHP on Windows is seen as a simple task.
7.       CHM file for PHP documentation script
Gennady told me that script which pulls in documentation and creates a CHM file is broken and need some fixes. He loves access to php documentation even when offline and want the script to work. I will be looking at it and try to fix it.
8.       Pre-built PECL binaries for Windows has been down for ages. Many showed frustration with the fact that pre-built PECL binaries for Windows are hard to get. Pierre has few extensions built regularly and has them available for download here. Getting binary for an extension which is not available here is as easy as sending Pierre an email. If you want to build the PECL extension yourself, you can follow the instructions here. We still need to look into or its replacement plans.
9.       Getting operating system information from PHP is hard
Elizabeth Marie Smith, in her awesome Cross Platform PHP talk, mentioned that getting system information on Windows is hard. I will be following up on this and make fixes to PHP as needed.
10.   Debugging dependency check errors is very hard
Elizabeth Marie Smith mentioned this in her talk. I will look into this and see what can be done.
I will be following up on each of these and hopefully will close on most of these requests before Tek-2011J. If this list doesn’t capture something you need for better php on Windows experience, please leave a comment and I will add it to this list.

Using IIS configuration tools to manage HWC configuration

I have seen many people built some innovative solutions on top of hostable web core (HWC) functionality which was added in IIS7. One of the questions which HWC users frequently ask is how to make IIS configuration tools (like appcmd, UI etc.) work against configuration file which their HWC instance is using. So far they have been either doing manual modifications to HWC configuration file or making changes to IIS configuration and then porting over to HWC configuration. There is an easier way to do this but caveat is that this requires your HWC configuration file name to be applicationHost.config. If that is the case, you can use IIS shared configuration feature to setup a redirection to your HWC configuration file. Below are the steps to get this working.
          Open %windir%\system32\inetsrv\config\redirection.config.
          Change <configurationRedirection /> to <configurationRedirection enabled=”true” path=”c:\HWCInstance\” />
          Save and exit.
With this change, configuration system will map MACHINE/CONFIG/APPHOST to c:\HWCInstance\applicationHost.config and assume this as the main configuration file containing applicationPools and sites information. Now appcmd, UI etc. will work against HWC configuration file. Please note that setting up this redirection will affect your main instance of IIS as well. So if you are using IIS and HWC in parallel, this won’t be a safe thing to do. But if you are not using IIS main instance and only running your own HWC instance, this can be used to make IIS configuration tools work against your HWC configuration.
Hope this helps.

WordPress widget to show WinCache statistics

Ruslan (, who is Program Manager for WinCache project, has been showing WinCache statistics on the right sidebar of his website for quite some time. Few weeks ago I decided to do the same but instead of editing theme source code and add the information there, I decided to write a standalone wordpress widget. Two days ago I finally wrote the widget which is aptly called wincache-stats. It shows statistics in a table format. First column of the table show cache type and number of entries in cache, second column show hit count and hit ratio and third column show miss count and miss ratio. It can be see in action on I submitted the widget to yesterday and it has been approved. So this is available for download from here. If you want to look at the source code, you can see it here. Below is a snapshot of the wincache-stats widget.
You can choose what statistics to show in the wordpress admin interface. Picture below shows admin interface of wincache-stats widget.
I hope some of the WinCache users use this widget on their website to see WinCache usage and in the process, help us spread the word about WinCache. If you want to report a bug or request a feature, please leave a comment to this blog.

PHP PGO build for maximum performance on Windows

In the last few years VC++ team have done some awesome work with profile guided optimizations (PGO). PGO improves performance of certain code paths which are more likely to be used in production environments. Most of the teams in Microsoft have been using this technology to speed up most commonly used scenarios. One of the ideas initially floated by Garrett was to start using PGO for building PHP. Garrett wrote a blog on how to produce a PGO build but the steps involved were little complex. I started looking into simplifying the process and came up with a simpler way. I am going to walk you through the steps I used in this blog. All the steps written in this blog are tested to work with VC9 compiler. I am assuming you already have a PHP build environment set. Go through this and this blog to setup a PHP build environment if you don’t have one. I am using PHPROOT environment variable to refer to root folder where PHP build environment is set. If you used winbuild.bat to setup build environment, PHPROOT refers to C:\php\php_sdk\php_53_dev\vc9\x86\PHP_5_3.

Note: PGO support is not available in VC++ express edition. To build PGO optimized binaries, you need a version of Visual Studio which supports this feature.
1. Add PGO support to build system
PHP build scripts, as available in PHP source tree, don’t have support for PGO. So first thing you need to do is download this patch to %phproot%\win32\build and apply it on your system. This patch will add support for “–enable-pgi” and “–with-pgo” options in PHP build system. When “–enable-pgi” option is used, PHP build system will add “/LTCG:PGINSTRUMENT” switch to linker command to build instrumented binaries. Option “–with-pgo” will make build system to add “/LTCG:PGOPTIMIZE” switch to linker commands. This switch will make linker use PGO data to produce final optimized binaries. Both “–enable-pgi” and “–with-pgo” cannot be used together. This patch will also make “nmake clean-all” option to delete PGO related files in addition to other cleanup tasks it already does. Additionally you will get an option to delete all files except PGO profile data using “nmake clean-pgo” command (used in step 4 below). After applying the patch, run %phproot%\buildconf.bat to regenerate configure.js again. You can verify this step by running “%phproot%\configure –help” and confirming that output shows “–enable-pgi” and “–with-pgo” options.
2. Build instrumented binaries
PGO build is a two-step process. First step is to collect data identifying most commonly used paths. Second step is to feed this data into build system which then optimizes these paths. Collecting training data requires you to build instrumented binaries which have code to collect profile data. Let’s go through steps to produce these instrumented binaries.
First delete the folder containing non PGO binaries using “rd /s /q %PHPROOT%\release” command. Open %PHPROOT%\config.nice.bat and add switch “–enable-pgi” option to the configure command. Run “config.nice.bat” to create a new makefile and use “nmake snap” to produce a PHP build containing instrumented binaries.

After the build is complete, you will see “.pgd” files created in the %PHPROOT%\release folder along with usual “.exe”, “.dll”, “.pdb” files. Build process uses php.exe to do few steps. So after the build is complete, you will see php!1.pgc and php5!1.pgc in release folder. Delete these files so that profile data doesn’t include code paths which were used during build process. Don’t touch any of the other files yet and move to step 3.

3. Collect training data
To collect training data, pick the build packages (php-*.zip and pecl-*.zip) from %PHPROOT%\Release folder and install it on your web server. For this blog I am training the binaries for wordpress. So I copied and installed instrumented binaries on my web server running wordpress. If your build machine itself has the web application installed, you can do this on the build machine itself. If your web server doesn’t have visual studio installed, it won’t have PGO runtime (pgort90.dll) which is required to run instrumented binaries. Pick this file from you build machine and copy to the folder your web server containing php-cgi.exe.
Now open “%windir%\system32\inetsrv\config\applicationHost.config” (for IIS 7.0 and IIS 7.5) or “%windir%\system32\inetsrv\fcgiext.ini” (for IIS 5.1 and IIS 6.0) and set PHP_FCGI_MAX_REQUESTS equal to number of requests you are going to send to cover most used paths. I changed this setting to 15. Keep “InstanceMaxRequests” setting in FastCGI process pool higher than PHP_FCGI_MAX_REQUESTS value so that PHP terminates itself before FastCGI forcibly kills it. When php-cgi.exe dies on its own, PGO data will be dumped to “.pgc” files. Now you are ready to collect training data.
Send requests which cover code paths you want to optimize the most. In my case, I sent 6 requests to home page and 6 to individual posts to identify these as the most requested parts of my website. I sent 2 requests to category home page and 1 to about page to optimize these paths as well but identified these pages as less hot than home page and individual posts. Choose these requests carefully and only send requests to most frequently visited pages so that this part gets optimized the most. If you cover too much surface area in training data, linker won’t be able optimize as effectively. After PHP_FCGI_MAX_REQUESTS, php-cgi.exe will die and dump “.pgc” files in PHP install root. Find and copy all the “.pgc” files in a folder and then copy to your build machine.
4. Merge training data and build optimized binaries
Copy all the “.pgc” generated in step3 to %PHPROOT%\release folder along with “.pgd” files. Run “nmake clean-pgo” to delete all files except “.pgd” and “.pgc” files. Now change config.nice.bat to use “–with-pgo” instead of “–enable-pgi” and then run config.nice.bat to generate new makefile. Run “nmake snap” to build optimized build and that’s it.

As PHP source code changes are incremental, you don’t need to collect training data for each build. For building latest PHP sources, you can just sync and run “nmake snap” again to use existing training data with latest sources. As source code changes increase, training data will be less accurate and less effective. You can update training data once a month and before the final release to produce useful PGO builds regularly. Run “nmake clean-all” before using new training data so that old training data is deleted.

To build non-PGO build, run “nmake clean-pgo” to delete all binaries (but keeping training data). Remove “–with-pgo” option from config.nice.bat and run it to generate new makefile. Use “nmake snap” to produce non-PGO build.
WordPress Performance Test Results
Let’s go through some quick results I got on my performance bench using PGO optimized build and compare it with non-optimized build from my build machine.

Response Time
Regular Build
726 ms
PGO Optimized
79.89 (17.40% better)
619 ms (14.74% better)
I got approx. 17% better throughput and 15% better response time with PGO build compared to non-PGO build for wordpress. For some other applications, I have seen as much as 30% improvement. If you are trying to get maximum performance output from your windows server, PGO build is something you should definitely consider. If you try out PHP PGO build and run into a problem, sending me email me will get you instant helpJ.

Adding a PECL extension to your PHP build environment

Last week I published winbuild.bat to setup PHP build environment on windows. In this blog I am covering how to add a PECL extension to the PHP build system. I will also show how to static link a PHP extension and how much performance benefit you can get by that.
Building a PECL extension
Let’s say you have the PHP build environment set in the folder c:\php\php_sdk\php_53_dev\vc9\x86\PHP_5_3. For adding PECL extension (e.g. WinCache) to the build process, first download source code of the extension in c:\php\php_sdk\php_53_dev\vc9\x86\pecl\ folder. You can use the following commands to do this.
pushd c:\php\php_sdk\php_53_dev\vc9\x86\
md pecl\wincache
cd pecl\wincache
tortoiseproc /command:checkout /path:. /url: /closeonend:1
Once you have downloaded the source code, follow steps below to add the extension to your build process.
1.       Open visual studio command prompt and run c:\php\php_sdk\bin\phpsdk_setvars.bat to set PHP build window.
2.       Go to c:\php\php_sdk\php_53_dev\vc9\x86\PHP_5_3 andrun buildconf.bat. This will make PHP build environment to create configure.js again with option to build WinCache.
3.       Run “configure –help” to confirm that –enable-wincache option is now present in configure options.
4.       Open config.nice.bat and add “–enable-wincache=shared” option to the configure command.
5.       Run config.nice.bat to generate new makefile.
6.       Run “nmake snap” to build full PHP or just use “nmake php_wincache.dll” to build only WinCache extension.
Running “nmake” command will create php_wincache.dll under c:\php\php_sdk\php_53_dev\vc9\x86\PHP_5_3\release folder. Steps above add PECL extension wincache to the PHP build system. You can add any other PECL extension to the build system by replacing wincache with that extension name. You can add multiple extensions by adding multiple switches to your configure command.
Static linking and performance comparison
Above steps used “–enable-wincache=shared” option in the configure command to add wincache to the build system. “=shared” tells the system to link the extension dynamically. Removing “=shared” from “–enable-wincache” or for that matter any configure switch will make that extension link statically. Performance with static linking is significantly better than when extensions are dynamically linked. If you know what PHP extensions you use, you can create a custom build with all those extensions statically linked. Let’s see how much performance improvement we get by statically linking wincache compared to when wincache is dynamically linked. I am using wordpress as the sample application.


Response time
Dynamic linking of wincache and mysql. All others as set by winbuild.bat.
68.05 requests/sec
726 ms
Static Linking of wincache and mysql extensions. All others as set by winbuild.bat.
72.12 requests/sec (5.98% better)
692 ms (4.68% better)
As you can see, just static linking of two extensions increased performance by ~5%. A custom build with needed PHP extensions statically linked will almost always perform better than official build from I hope that my last blog and this blog makes it easier to create custom PHP build on windows. I am experimenting with PGO builds these days and I will share my findings about that soon as well. Till then, CHAO.