IIS7 PHP WSDL issue

If you ever run into a scenario where you need to run a PHP SOAP webservice in an IIS environement, you might encounter the following problem. When generating a client proxy in .NET/WCF this exception is thrown;

The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

The problem, as it turns out, is that ASP.NET appends the HTTP X-Powered-By header. This header seems to confuse the proxy generation code. To fix the issue you need to remove this IIS header. Head to your IIS Manager > You website > The folder your PHP webservice is located > Click HTTP Response header. Then remove the X-Powered-By header. Now enjoy generating proxies!

Some evil internet voices claim that you should set useUnsafeHeaderParsing to false in your clients’ application configuration to make .NET ignore the inconsistency in your webservice WSDL output. This however is a workaround, not a solution. So if you run the webservice apply the header fix as described above.

Remove IIS headers

Magento LAMP vs WIMP: Running Magento with IIS and WinCache

Let’s get started by getting IIS up and running with WinCache. Getting your IIS up and running with PHP itself is easy. Add the IIS role to your Windows Server setup in the Feature Manager and browse to the PHP IIS website. Once there, hit the big blue “Install PHP” button and let the Microsoft Web Platform Installer do it’s magic.

When you’re done, point your browser to this page. Another “install” button is presented. But for some reason this one does not always work (it didn’t in the Windows 2008 R2 Web edition I was using). So here’s how to get WinCache running Manually;
1. Download WinCache for PHP 5.3 from sourceforce.net.
2. Extract php_wincache.dll to “C:\Program Files (x86)\PHP\v5.3\ext”
3. Edit “C:\Program Files (x86)\PHP\v5.3\php.ini” and at the bottom of the file add the line “extension=php_wincache.dll”.
4. Extract wincache.php to your webroot. By default it’s somewhere like “C:\inetpub\wwwroot”.
5. Edit wincache.php and change the username and password in lines 42 and 43.
6. To be sure, restart IIS using yout IIS Manager.

Now browse to yourdefaultwebsite/wincache.php. If you hit a screen like the one below, your glasses are OK. If not, scream out lout and start asking for help…

WinCache statistics

WinCache statistics

Set up Magento to use WinCache
Back to Magento. The first part of WinCache, the opcode cache, kicks in a few levels below Magento. Magento does not know it’s there and does no need to. The opcode cache will keep a copy of the interpreted PHP opcode (created by the PHP binary when intepreting PHP files) in memory. It will use this copy each time a cached script is executed saving CPU cycles and IO operations (at the cost of a little memory). An opcode cache is vital for decent Magento performance. If your webhost does not implement one, sue them for stupidity (just kidding, don’t reference me in court).

The second part of WinCache we will want to use is the user cache. A user cache can be seen as a kind of dictionary. You can put data in it by attaching a label to it. When you want to extract that data at a later time you can access it by using that label. Magento comes with it’s own caching system. It can cache lots of things (System -> Cache management). It does this by utilizing the cache classes in the Zend Framework on which it is build.

To store all this cache it needs a backend. By default Magento will use the filesystem as its backend. It’s wise to keep it this way as the filesystem is the most likely to have space and is allways available. But it’s also wise to add a second backend that is a hell of lot faster then your filesystem. This is where we will want to use the WinCache data cache. Using these two backends is made possible by the TwoLevel cache. More on that in this great post by Fabrizio Branca.

Enable WinCache as the fast cache backend
The Zend Framework handles the backend itself, Magento just uses the interfaces/classes provided by the Zend Framework. At present the code required to use WinCache as a cache backend in not present in the Zend framework that ships with Magento. It is available in Zend framework 1.11. I’ve extracted the proper files here (download). Just download the zip and extract it’s contents to the root of your Magento installation to add WinCache data cache support to Magento 1.6+.

When that’s done we’ll need to configure Magento to use WinCache as it’s fast cache backend. Edit your app/etc/local.xml file and add these lines in the section;


     Zend_Cache_Backend_WinCache
     file

After saving your local.xml file be sure to flush Magento’s cache; System -> Cache management -> Select all -> Refresh -> Submit. When you check your wincache.php file again entries should show up under both “User cache” and “Opcode cache”.

URL Rewrites
Something else to think about when using Magento with IIS (or any other webserver then Apache) is to handle URL rewrites. IIS 7.5, which ships with Windows Server 2008R2, comes equipped with it’s own Rewrite module. By default the Magento installation contains .htaccess files which, among other things, instruct Apache’s URL Rewrite module how to handle the URL mappings. IIS does not use these .htaccess files. The IIS equivalent is the web.config file. Use a web.config file (which you have to save in your webroot) like the one below in order to use URL Rewrites (which you really should when doing this in production);






      
      
        
        
        
      
      
    
    



At this point we’re all done. Magento is up and running with IIS using WinCache.

This series of posts will compare typical, non-tweaked, LAMP and WIMP stacks, in terms of performance, running Magento CE 1.7.
Table of contents (work in progress)
1. Introduction
2. Running Magento with IIS and WinCache
3. Benchmarks (coming soon)
4. Conclusion (coming soon)

Magento LAMP vs WIMP: Introduction

When choosing a webserver stack, used to run PHP applications like Magento, a LAMP (Linux Apache MySQL PHP) stack is favored. Although nginx with php-fpm is on the rise, Apache on Linux is still the most popular choice. When choosing a reactor pattern based webserver like nginx or lightspeed, which some claim perform better under load, Linux is still the most popular choise. In fact here at RapidCommerce, all Magento hosting is done using Linux and a mix of Varnish/Apache/Nginx.

There is a “new” kid in town though, IIS. Obviously IIS does not run under Linux, its THE Microsoft Windows webserver. And it has never been popular to run PHP/MySQL based applications. With good reasons, I might add. IIS6 was a terrible performer when it came to PHP. However for IIS7 things have changed, so they say. Apparently the team behind IIS has been working closely with the PHP guru’s at Zend.

Add to these improvements in IIS7, the availability of a new opcode and user cache; WinCache. I started to wonder… How does this “new” WIMP (Windows IIS MySQL PHP) stack compare to the widely favored LAMP stack? So I decided to put things to the test. This series of posts will compare ZendServer CE (from those same gurus involved in improving IIS/PHP) with IIS7.

Both stacks can be seen as “out-of-the-box” PHP application servers. Both come with their own opcode cacher, Zend Optimizer+ with Zend Datacache SHM versus WinCache. Zend chose to run PHP as mod_php in Apache and in IIS PHP is run with FastCGI. I will acknowledge that adding Nginx/php-fpm and Apache/fast-cgi would be more fair, as they use a more comparable way to integrate PHP with the webserver. But I trust the guys at Zend know what they are doing and had their reasons to use the mod_php. The point being, out-of-the-box vs out-of-the-box. To make thing more comparable we’ll add Zend Server CE under Windows to the mix.

LAMP vs WIMP

This series of posts will compare typical, non-tweaked, LAMP and WIMP stacks, in terms of performance, running Magento CE 1.7.
Table of contents (work in progress)
1. Introduction
2. Running Magento with IIS and WinCache
3. Benchmarks (coming soon)
4. Conclusion (coming soon)

Link object popup failing in XAF after deployment

Last week I deployed an XAF Web application to one of our production servers running IIS 7. All seemed well until I noticed that all Object Link windows (the popup that allows you to make associations between existing objects) missed the grid control and the image. The button where there but without the grid the popup isn’t very useful is it…

Turned out that the web.config (which was generated at project creation trough a New Project -> XAF template) contained this line;


The problem being here this handler will not used unless “runtimeVersionv2.0″, which in my production IIS 7 server was not the case. Removing the runtimeVersionv2.0 precondition fixed things…