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

Da qualche tempo PHP ha iniziato a rilasciare anche delle build per Windows a 64bit, probabilmente in previsione del lancio della prima versione 64bit non sperimentale per la versione 7 di PHP. Sono attualmente disponibili le versioni x64 sia di PHP 5.5 che 5.6 oltre che ovviamente dell’ultima nata. Il framework dispone anche della corrispondente versione a 64 bit per la OpCache distribuita con i file compilati per Windows ma la sorpresa è che invece il modulo WinCache che Microsoft ha sviluppato qualche anno fa per migliorare le prestazioni di PHP (e che spesso viene considerato uno dei migliori moduli di accelerazione disponibili) non ha invece distribuzioni a 64bit ufficiali.

Certamente quelle versioni di PHP non hanno molto seguito in ambiente Windows e questo non ha spinto Microsoft a fornire versioni diverse del proprio acceleratore ma ora che ci sono delle distribuzioni ufficiali a 64bit per PHP 5.5 e 5.6 sarebbe comunque positivo poter integrare la OpCache di Zend e WinCache di Microsoft. Da notare che per PHP 7 la versione x64 di WinCache è prevista ed in fase di testing.

Per fortuna sul Web qualcuno ha pensato di compilare a 64bit il modulo WinCache e renderlo disponibile ! Questo sito Web ha delle build a 64bit per PHP 5.5 e 5.6 fino alla versione 1.3.7.4 di WinCache, forse non l’ultima build ma comunque molto recenti visto che l’ultima ha data 30/3/2015.

La domanda quindi è: funzionano ? Ovviamente non le abbiamo provate tutte ma possiamo dire che The Server-Side Technology usa ora PHP 5.6 x64 con la versione di WinCache 1.3.7.4 disponibile sul sito che abbiamo indicato. Abbiamo avuto grandi risultati con PHP7 ma alcune parti del nostro sito non erano al 100% compatibili e siamo ritornati a PHP 5.6, mantenendo però la versione a 64bit come base. Se avete quindi bisogno della versione 64bit del modulo WinCache, per adesso possiamo consigliare di provare quelle compilazioni: non sembrano esserci problemi particolari di compatibilità. Del resto, dovrebbero essere solo compilazioni a 64bit dei file originali….

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

Qualche settimana fa la comunità PHP ha pubblicato la versione 5.4.45, comunicando nel contempo che questa sarà l’ultima versione rilasciata della linea 5.4 del popolare framework di sviluppo. Questo rilascio include circa 10 fix di sicurezza e nessun ulteriore aggiornamento verrà pubblicato a meno che non vengano rilevati bug seri che costringano ad un ulteriore rilascio. E’ quindi consigliabile e raccomandato dalla comunità di PHP di iniziare gli upgrade delle proprie applicazioni alla versione 5.5 o 5.6. Inoltre, proprio ieri è stata rilasciata la RC4 (Release Candidate) di PHP 7 che, tra le altre cose, promette di essere di quasi due volte più veloce della versione 5.6, oltre che essere probabilmente la prima versione di PHP con supporto per applicazioni a 64bit.

Con un post su GitHub,  Damian Edwards ha annunciato che la nuova release di ASP.NET, la versione 5, non verrà più eseguita da IIS come ISAPI ma attraverso il modulo HTTPPlatformHandler che per l’occasione verrà aggiornato con alcune modifiche e reso disponibile anche per Windows Server 2008R2, la versione minima per eseguire ASP.NET 5. La modifica sarà disponibile già con la beta8 del software e quindi al prossimo aggiornamento previsto per il 5 Ottobre 2015.

ASP.NET ed IIS

A prima vista questa modifica potrebbe sembrare ininfluente ma segna un cambiamento piuttosto importante se si considera che sin dalla sua introduzione con IIS 6 e Windows Server 2003, ASP.NET è stata eseguita da IIS come ISAPI, la configurazione che garantiva le prestazioni migliori sulla piattaforma. Lo stesso avveniva ed avviene per altre tecnologie come ASP classico mentre storicamente altri framework o estensioni provenienti dal mondo Unix usavano invece una tecnologia meno sofisticata a cui si fa riferimento in generale come CGI.

Le perplessità potrebbero sorgere proprio perché da sempre l’esecuzione ISAPI è considerata la più efficiente e quella capace di fornire prestazioni di molto più elevate sulla piattaforma Windows Server, soprattutto perché la creazione di nuovi processi è in effetti una operazione onerosa sui sistemi Windows, molto più di quanto lo sia sui sistemi Unix.

In realtà sin da Windows Server 2003 Microsoft ha affinato il supporto per le tecnologie CGI, in particolare per garantire la compatibilità con framework molto popolari come PHP. La tecnologia FastCGI è in effetti l’antesignana del modulo HTTPPlatformHandler e, sebbene con FastCGI la piattaforma Windows Server abbia efficacemente ottenuto l’esecuzione di framework come PHP con prestazioni pari o addirittura superiori a quelle dei sistemi Unix, fino a poco tempo fa era considerato impossibile che Microsoft decidesse di passare ad una modalità di esecuzione diversa per le proprie tecnologie.

HTTPPlatformHandler : l’evoluzione della specie

La notizia non può che significare che Microsoft ha ormai ottenuto una parità di performance tra l’esecuzione ISAPI e quella CGI e la chiave è senza dubbio il modulo HTTPPlatformHandler. Anticipando le perplessità di qualcuno, Edwards aggiunge che Microsoft si aspetta una differenza di prestazioni tra le due modalità solo per applicazioni triviali come una Hello World, cioè piccole applicazioni che fungono più da esempio che da reali implementazioni. Per tutti gli altri casi, probabilmente Microsoft crede di raggiungere prestazioni uguali o anche maggiori a quelle ottenibili con la tecnologia ISAPI. Certamente così facendo ottiene una flessibilità notevolmente maggiore, soprattutto in un contesto nel quale ASP.NET è diventato open-source ed in teoria qualsiasi utente potrebbe compilare la propria versione della tecnologia.

Il modulo HTTPPlatformHandler è l’evoluzione di quello FastCGI che ha consentito a Windows Server di diventare una piattaforma ideale anche per PHP a partire dalla versione 2003 e da IIS 6. FastCGI risolve il problema dell’onerosità della creazione di nuovi processi con l’attivazione di una singola istanza che verrà usata in modo efficace da IIS per gestire un numero variabile di richieste, isolandole da quelle degli altri siti Web ma gestendole sempre con un processo unico. Di tanto in tanto, in modo configurabile, [...]