How to run PHP 7 x64/x86 on Windows Azure Pack

PHP 7 has been released on December 3rd and its first update (v7.0.1) has been released on December 17th. This new version brings a lot of changes in, including major performance enhancements compared to PHP 5.6 (up to a 2x performance increase!), better (meaning reduced) memory footprint plus support for 64bit runtimes. There are of course many other enhancements but those three alone should provide a good reason to update websites to the new version. There could be problems in doing so if you are using deprecated or non-supported code but if your application followed recommendations, you should be able to upgrade to PHP7 and enjoy the enhancements.

There are a few handful extensions that bring PHP7 (RC and now RTW) to Azure but those extensions, while providing a good starting point, are not compatible with Windows Azure Pack because of a few hiccups in installation scripts (basically referencing D: drive, as in Azure, instead of C: as in WAP or using %HOME% environment variable to solve this problem and keep the scripts compatible with both). However, this is a good chance to explore once again the flexibility of Windows Azure Pack and configure PHP7 on our own, something useful to update/upgrade at a later time, if needed, without waiting for someone else to provide a new script for it. Having PHP 7 working could be useful to upgrade compatible applications like WordPress, which is already compatible with this new version.

This tutorial has been tested on VaiSulWeb Cloud Hosting services. As our company provides a free account for development and testing, it is easy to start working with PHP7 or ASP.NET 5 by the way. Head up on our website to request your free account.

[section label=”Getting started”]Getting started

As a first step we need to download PHP7 from its website, taking care to download Windows binaries we need for our tests. Head to download page and look for VC14 x64 Non-Thread-Safe (NTS) distribution (php-7.0.1-nts-Win32-VC14-x64.zip) as we want to experience x64 version for our tutorial. Once downloaded, we can unZIP that file and move its contents to our site via FTP. We will upload file contents into /site/bin/php folder so our file structure will be like this:

site/

bin/

php/

dev
ext
[…]
php.ini
[…]
php-cgi.exe
[…]

wwwroot

Now that we uploaded a new PHP distribution to our website, we need to solve two problems before being able to run our own PHP runtime: the first one is telling WAP that we want to use this new version in place of runtimes automatically supported by the platform (v5.3 through v5.5) as shown below:

 

The second problem we have is to tell PHP where to find its configuration file, the famous php.ini. When using default runtimes, Azure Pack will tell PHP where to find its configuration file but now we want to use a custom runtime so we need to find a way to point PHP to the INI file that we will upload into /site/bin/php/ folder. For now, we will just rename php.ini-development file that is shipped with PHP we just downloaded to php.ini. If you didn’t do that earlier, do that now.

Note that we uploaded the runtime outside the wwwroot folder that will host our PHP files and all associated assets. While the runtime can be placed everywhere inside our account, including as a subfolder inside wwwroot, it’s a good habit to place such files outside the Web-accessible folder for security reasons. That’s the same folder structure used by the new ASP.NET 5 runtime.

[section label=”How to use the new runtime”]How to use the new runtime

Now that we uploaded the new runtime, we need to switch the handler for PHP websites. Settings for supported runtimes don’t appear inside your control panel as the path is automatically injected into the runtime when php-cgi.exe is called to run a script/page. However, default settings know nothing about PHP7 and its files so we need to change that and tell IIS where php-cgi.exe actually is.

This might look difficult and there are multiple ways to do that, actually, but the simplest way is to add a new entry for PHP files in our handler mappings section of our website as shown below:

Don’t forget to save settings and restart your website. Now your website will run the new runtime when invoking a PHP file but we have another problem to solve.

[section label=”Telling PHP where its configuration file is”]Telling PHP where its configuration file is – the easy way

There are a couple of ways to tell PHP where to look for its configuration file. The easiest and quickest way is to explicitly tell PHP its full path and file name via handler mappings section of our portal. Each time php-cgi.exe will run, it will load the configuration file that you provided and since those FastCGI processes will be reused, that will happen just once per several thousands requests. Configuring the handler is rather easy, as confirmed by the screenshot below:

As you can see, you just add a path to the php.ini file using the “-c” argument supported by php-cgi.exe. You can also use %HOME% environment variable to avoid having to pass the full physical path to the file, usually located inside the PHP folder itself but that can be located where you want.

After restarting the website, if you now try to run a PHP file, like for example a simple phpinfo() call, you will be greeted by the familiar information output, as shown below:

Well done ! But how can we say if we’re actually running the 64bit version of PHP 7.0.1 ? There’s an easy way to do that thanks to this Stackoverflow script:

If you simply put this file in your Web root (for example as check64.php) you can run it to get a confirmation that you’re running 64bit PHP 7.

[section label=”Optimizing your PHP7 experience”]Optimizing your PHP7 experience

Now that PHP7 is running, there are a couple of settings that can be changed to provide better performances. First of all, PHP 5.5+ now provides an internal module to implement OpCache functionalities. Many websites used a PHP accelerator to achieve better performances through various layer of caching. On Windows platform, WinCache has been long used to speed up PHP. Microsoft released a new version of WinCache developed for PHP 7 but (since PHP 5.5) has deprecated its opcode caching and suggests to enable PHP own OpCache to implement those functionalities.

So, first of all, let’s enable PHP own OpCache as recommended by adding to our php.ini :

right after this line:

engine=On

Since that is a Zend module, we need to add it early inside php.ini so adding it right after engine directive is a good place. Note that we cannot use %HOME% environment variable here so we need to type the physical path. There are many settings that can be customized for OpCache but that single directive is enough to enable it using standard settings. Don’t forget to restart your website. You should now be able to see OpCache running for your website as shown below:

Now we can also add WinCache to the mix. Let’s first download it from:

http://sourceforge.net/projects/wincache/files/wincache-2.0.0/

Remember to download file wincache-2.0.0.2-7.0-nts-vc14-x64.exe to get the 64bit version of that file. Now upload file php_wincache.dll to the /site/bin/php/ext folder of your website and let’s edit php.ini again to include

extension = php_wincache.dll

Save php.ini and restart website to ensure the new directive is active. You should see WinCache among loaded modules for your phpinfo output. Here again, default settings.

[section label=”Summary”]Summary

This tutorial aimed at showing how flexible Windows Azure Pack is by even allowing to customize the environment to include runtimes not officially supported yet. We have been able to get control about how to handle PHP files by changing default behavior, deploy a new runtime, switch to 64bit processes, customize php.ini and add both OpCache and WinCache and we didn’t need support by the hoster for any of such operations.

At VaiSulWeb, we are switching toward this new model for our Web hosting services and we are currently hosting any size of website, from very small personal websites to very big ones (with millions of displayed pages per month) and our customers are enjoying unmatched flexibility and performances. I have to recommend to give our Cloud Hosting services a try by activating a free account that will allow you to test new runtimes like ASP.NET 5 or PHP 7. While such accounts don’t provide 64bit support we discussed here, they allow most of the functionalities discussed in this post.