PHP7 è stato rilasciato il 3 Dicembre di quest’anno ed il primo aggiornamento (la v7.0.1) ha seguito a ruota il 17 Dicembre. Questa versione introduce molti cambiamenti, inclusi molti miglioramenti alle prestazioni quando si effettua un confronto con PHP 5.6 (si parla di un raddoppio delle prestazioni!), una gestione migliore della memoria che porta le applicazioni a consumarne meno ed il supporto per i runtime a 64bit. Ci sono ovviamente altre novità ma questi tre miglioramenti sono già di per sé una buona ragione per passare alla nuova versione. Ci potrebbero ovviamente essere problemi che impediscono l’aggiornamento alla v7, ad esempio codice non supportato o non più raccomandato, ma se le vostre applicazioni lo consentono l’upgrade potrebbe essere consigliato per migliorare le prestazioni complessive.

Ci sono alcune estensioni che consentono l’installazione di PHP su Azure per iniziare ad usare da subito il nuovo framework ma queste estensioni non sono utilizzabili con Windows Azure Pack e gli hoster che ne fanno uso perché gli script di installazione hanno qualche problema, in particolare facendo riferimento al drive D: (come richiesto da Azure) invece che al drive C: (come richiesto in WAP) nel percorso virtualizzato o usando la variabile di ambiente %HOME% per essere compatibili con tutti e due gli ambienti. Questa è però una buona occasione per esplorare ancora una volta le possibilità di personalizzazione di Windows Azure Pack e configurare PHP7 da soli, una cosa molto utile per capire il funzionamento degli account WAP e poter effettuare aggiornamenti successivi senza la necessità di attendere il rilascio di un altro script. Avere a disposizione PHP7 può essere utile sia per sviluppare applicazioni che usino il nuovo framework sia per usare applicazioni compatibili come WordPress, che da qualche tempo ha effettuato un refactoring del proprio codice per renderlo compatibile con la nuova versione del framework… estensioni, plugin e temi permettendo !

Questo tutorial è stato provato con i servizi di Cloud Hosting di VaiSulWeb e considerato che la nostra azienda consente l’attivazione di account gratuiti per il testing e lo sviluppo, è facile iniziare a lavorare subito con framework di nuova generazione come ASP.NET 5 o PHP7. Visitate il nostro sito Web per richiedere il vostro account gratuito.

Per iniziare

Per iniziare servirà ovviamente scaricare PHP7 dal sito ufficiale, facendo attenzione a scaricare una distribuzione per Windows che è quella che servirà per i nostri test. Possiamo navigare quindi sul sito Web di PHP e cercare una versione contrassegnata da VC14 x64 Non-Thread-Safe (NTS), ad esempio php-7.0.1-nts-Win32-VC14-x64.zip. Quando il download terminerà, possiamo decomprimere il file ZIP e trasferire i file estratti sul nostro sito Web attraverso FTP. Inseriremo i file nella cartella /site/bin/php in modo che la struttura delle nostre cartelle sia simile a quella evidenziata di seguito:

site/

bin/

php/

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

wwwroot

Ora che abbiamo PHP sul nostro sito Web, dobbiamo risolvere due problemi prima di poter usare il nuovo runtime: il primo è comunicare all’ambiente di hosting che vogliamo usare questa nuova versione invece che una di quelle [...]

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.

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:

PHP runtimes available through Windows Azure Pack portal

 

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. [...]

Windows Azure Pack is a great technology but sometimes Microsoft seems to be missing the complexity of providing services to hundreds if not thousands of customers, each of them with different needs. Standardization is good but it should provide enough flexibility to manage things in a reasonable way. So here’s the scenario: you deployed WAP and your customer starts to buzz into your server because how good WAP actually is. Rock solid, able to run most demanding websites. Great technology, I said.

However, one of your customers runs over his allotted quota of one of the seventeen metrics you can monitor for your websites. Since your customer didn’t opt for a pay-per-use billing model, you just suspend his website, like any hoster in the world would do, and your customer calls in to buy more “of that something”. He pays (if needed), if you’re like us he gets an add-on to increase his quota over a standardized plan and, after a while and a little synchying, WAP states that his account is now back in quota. End of story.

Well, almost! Because your customer calls in again stating that his website is still suspended while on his portal he sees no over-quota warnings and you realized that he is right: no warnings, increased quota but website still suspended. Hmmm…

From now on, you start a journey to understand why WAP didn’t re-enable that website. You try to update plans, subscriptions, add-ons, force subscription resynchying, force plans to update, open-up Powershell to look for a well-hidden parameter that will allow you tell WAP to re-evaluate quota and re-enable website, or (at least) a cmdlet to tell WAP to re-enable that #&%$@#!$ website because I’m the one who rules here. Apparently, you discover that there isn’t anything like that: no way to re-enable a website that is over quota. So you basically look at portal where it states that counters will be reset in 29 days and you start thinking if WAP really wants to re-evaluate quota in 29 days from today. You wait in the hope that it will take a little time to start that website again but no luck. After hours, you really start to think that WAP will keep that website suspended until it will be time to reset counters, which is obviously totally unacceptable. But the most scary thing is that you cannot force it to change his mind. You’re basically powerless.

After a little checking, it turns out what I stated is not true for all quota items. For example, a short while after upgrading (by adding an add-on) sent bytes quota, a suspended website has been restarted by WAP itself. However, there are other counters that seem to be evaluated only when their configured period will expire, for example CPU burst and received bytes. No matter how long you wait after changing those, WAP won’t restart the affected website. I’m talking about hours here, not minutes, but I couldn’t wait days to check if it would happen after 29 days as suspected. [...]

A few days ago Microsoft released ASP.NET 5 beta8, the first feature-complete version of its flagship Web framework. A lot of expectations come with this new version, both because Microsoft decided to change ASP.NET down to its basis and because this one will be the first multi-platform release for the technology, allowing developers to run their Web or console applications on Windows, Linux and Mac OS X. However, the new version will also be the first one designed from the ground up for the cloud era and thus adopting all methodologies, technologies and conventions that emerged in past few years. As we detailed in a past article (sorry: Italian language only this time!), ASP.NET 5 will also change the way ASP.NET will be hosted on Windows because it will run through the famous HTTPPlatformHandler module that enabled Azure to run basically any runtime, including Java, Python, RoR and more. Later, that module has been channeled down to partners and Windows Azure Pack incorporated it in UR7.

You might be running your website or application on Windows Azure Pack and, if you do, I do really hope that you’re hosting with us at VaiSulWeb since we also have free accounts for you to try ASP.NET 5. However, even if you’re hosting at another service provider, you might be wondering if you will be able to run ASP.NET 5 starting from beta8, since this version switches to HTTPPlatformHandler. Up until beta7, hosting with Azure Pack was very easy: you only needed to publish your project to a folder and then upload that package to your WAP account. Everything was working fine since the very first second.

Spoiler: scroll down for a quick solution

There’s a quick solution waiting for you at the end of this article. If you’re only interested in understanding how you can run ASP.NET 5 from beta8 using WAP, just skip this lengthy explanation and run to the end. This article will be used to as an handy excuse to showcase some nice features that Windows Azure Pack provide its users and that our company provides its customers. We will use such features to understand what’s going on with beta8 and then provide a quick solution to host it on WAP.

Publishing your beta8 to your WAP account : Redmond we have a problem…

So you just started a new project based on ASP.NET 5 beta8 in Visual Studio 2015 or you just created a template project to check how things would shape up. Quick and easy. Now you would like to upload that project to your Web hosting account to check if your provider is compatible with the technology. So you just export your project…

Publishing your project to file system

… publishing to file system, the same way you did up to beta7. Then, after that operation completes, you upload your project on your WAP accounts via FTP or WebDeploy. Compilation time, just a few seconds, and then… uh ?

It seems that something went wrong since no shiny MVC homepage appears in your [...]