Ruim één jaar spinde onze WordPress-site op ’n virtuele LAMP: Linux, Apache, MySQL met PHP.
Azure App Service
Vandaag hebben we eindelijk de overstap gemaakt naar Azure App Service, voorheen bekend als Azure Web Sites.
Learn From My Fail: Test langer dan paar uurtjes voordat je via DNS-change live overgaat ?Vanaf het prille begin wilden we onze website op Azure hosten, omdat we immers de Microsoft-platformgedachte omarmen. Toen hadden we echter nog geen Azure credits; nu maandelijks 130 virtuele euro’s per persoon. Vervolgens zochten we een makkelijke en stabiele (bovendien gratis) plugin voor de WP-migratie van de ene host naar de andere.
Na de vlotte migratie begon WordPress op Azure App Service geregeld server errors (HTTP/500) uit te spugen. Standaard stond PHP 5.6 aan en dat hebben we nu op PHP 7 gezet. Dusver geen foutmeldingen meer.
De performance is nog steeds verre van optimaal. Op zich opmerkelijk, want onze website draait nu op een Azure App Service S1-plan dat 1 core en 1,75 GB heeft. Meer dan genoeg zou je zeggen voor een paar honderd bezoekers per dag. Een collega heeft zijn WordPress verhuisd naar een virtuele machine op het Azure-platform met dezelfde specificaties en zijn site reageert véél directer. Wellicht dat we ook maar die route gaan bewandelen als na fine-tuning de boel toch te langzaam blijft.
Geef jouw feedback over de performance tot die tijd hieronder aan.
Foutmeldingen mag je natuurlijk ook melden, alhoewel we deze nu wel netjes doorkrijgen van Azure Application Insights; érg gaaf en handig.
Updates
08-aug 21.55
Het publiceren van een post duurt nog steeds érg lang, zelfs met een time-out tot gevolg. Blijkbaar is de blogpost wel gepubliceerd, maar de CPU- en responstijden spreken boekdelen:
08-aug 22:15
Meer dan de helft van actieve plug-ins in WordPress gedeactiveerd. Weliswaar minder functionaliteit, maar de snelheid is omhoog geschoten. Waarschijnlijk zitten er enkele buggy plug-ins tussen die we deze week vast vinden. De performance bij (her)publicatie en previews is nog steeds zeer matig.
09+10-aug
De twee dagen na livegang hebben we een aantal changes doorgevoerd:
❌ Local Cache gebruiken in Azure App Service, maar toen non-stop Internal Server Error (http 500) dus vervolgens deze optie als Web Application Setting weer verwijderd.
✅ WP-Cron deactiveren, alleen als Azure Web Job draaien levert dezelfde HTTP/500 errors op
‼ Echter, in de Azure console zagen we nu iets meer details, namelijk de additionele foutmelding:
Error establishing a database connection
✅ PHP memory verhoogd naar 512M
✅ PHP-versie verhoogd van 5.6 naar 7.0 en uiteindelijk 7.1 toen de HTTP 500 server errors bleven
✅ Azure App Service Plan verhoogd van S1 (Small; 1 CPU met 1,75 GB RAM) naar S2 (Medium; 2 CPU met 4 GB RAM)
Leer in ieder geval van mijn fout: test véél langer dan ’n paar uurtjes voordat je via DNS-wijziging naar Azure omschakelt. Je kunt immers via https://<JeWebAppNaam>.azurewebsites.net uitvoerig testen.
Bonustip: gebruik https://<JeWebAppNaam>.scm.azurewebsites.net voor onmisbare troubleshooting tools, zoals een debug console en (live) logs. Samen met Diagnose and solve problems in het Azure portaal en Azure Application Insights hebben we toch aardig wat inzicht gekregen in de problematiek. De beruchte Internal Server Error (HTTP/500) duikt zo nu en dan nog wel op maar minder frequent. De performance lijkt ook een stuk beter, gemiddeld onder de 1s.
Hoe is jouw gebruikerservaring nu op wow365.nl sinds onze migratie naar Azure Application Service?
Verzameling screenshots tijdens troubleshooting: Error 500 overview
Hallo Mike,
Bedankt voor de updates. De gebruikerservaring is nu een stuk beter dan voor de migratie. Vlak daarna inderdaad wel wat van die error 500 foutmeldingen maar niet meer gezien nu. Pagina’s laden nu lekker snel, ook mobiel. Super!
Fijn om te horen, dank voor je feedback!
Belangrijke noot: mogelijk dat na de migratie naar Azure ook jouw WordPress JetPack stats gereset zijn. Zo ja, simpelweg gratis support ticket inschieten via je WP dashboard. Oorzaak lijkt doordat Azure onderwater een {AzureAppServiceNaam}.azurewebsites.net hostnaam gebruikt dat WP’/Jetpack als default lijkt te gebruiken en daarom een nieuw ID genereert. Na de merge gelukkig weer de statistieken gedurende 2 jaar terug.
Hello, WordPress wasn’t always the best experience when running on App Service, but maybe you could try App Service on Linux (in preview at the moment). Since it runs natively on managed Linux (through Docker containers), it could give you a lot of benefits. Here’s a link with some more info: https://docs.microsoft.com/en-us/azure/app-service/app-service-linux-readme
I have been running WordPress on App Service for couple of years now without a single issue.
Thank you, Jan – I hadn’t heard from App Service on Linux yet. Worth a try with one of our other websites since I’m gonna play MC Hammer on this one: Can’t touch it 😉
Your name and website already rang a bell when I saw your comment by email, since my coworker pointed to your blog for me to try out Local Cache. That appeared to break WordPress on Azure App Service (Windows) so my burning question: do you run your WP blog on Windows too and if so, with Local Cache enabled? Also wondering which database you’re using. Thanks again!
Okay, let’s start with the easy part – database:
Currently, we are using MySQL hosted in a virtual machine, the ClearDB instances had a lot of performance issues. Once Azure Database for MySQL (https://azure.microsoft.com/en-us/services/mysql/) makes it out of preview, we are going to switch ot it. Generally, running it in a VM is really fast and gives you enough freedom (which ClearDB did not).
As for Local Cache – we are not actively using it on production WordPress sites, but using it with osTicket for example. The reason is, that WordPress heavily relies on the persistent storage – for example image uploads, which get directly uploaded to the site’s filesystem. This behavior can be changes, you can for example save all upload into Azure Storage which provides great storage capabilities, however, another issue are plugins and WordPress updates. Since plugins are saved directly into the persistent storage as well, you would have to disable the Local Cache everytime you decide to update a plugin or WordPress itself. That is generally bad, because it prevents WordPress from self-updating.
What we did to speed up the site loading is to use CloudFlare as a caching proxy and WP Super Cache to cache the generated content on server-side. It works really nice for our sites.
Thank you so much for your detailed and insightful answers, Jan – much appreciated!
We also use CloudFlare (and loving the tons of free services, also those page rules to e.g. redirect http://www.wow365.nl to host without www and enforce SSL).
Recently switched from WP Super Cache to Total Cache since somehow WP Super Cache and WPTouch (for mobile theme) kept conflicting.
We’ll keep an eye on Azure DB for MySQL since we (read: I 😉 are fed up with system maintenance, especially when it’s Linux, thus prefer PaaS solutions. Also good to get confirmed that WP is not the ideal candidate to use Local Cache. Thanks again, keep up the great work on your blog!