This blog has had a variety of homes over the past few years although you wouldn’t know it by looking at it. Initially it was hosted on a Windows 2008 server I built myself, sitting behind the tenuous link of my ADSL connection. Don’t get me wrong this is a great way to get started if you’ve got admin roots like me but inevitably my ADSL connection would go down or people would just plain give up waiting for it to load, what with my upstream only able to handle 100KB/s. Still for most of its life the blog remained in that configuration as I couldn’t find a hosting provider I was happy with.
Of course the day came when WordPress decided to stop playing nice with IIS and started returning internal server 500 errors. Thankfully it would usually right itself after a reboot but it was always a count down to the time when it would start erroring out again and being the busy man that I am I never had the time to troubleshoot it. Eventually I caved and set up an Ubuntu box to host it, figuring that all my woes would be solved by switching to the platform that everyone expects WordPress to run on. I’ll be honest it was a good change as I could finally use all the caching plugins, and traffic took an upward trend thanks to the faster loading times.
Unfortunately that didn’t last particularly long either as whilst the blog was particularly zippy the Linux VM would sometimes stop responding to requests and would only start behaving itself after a reboot. The cause of this I’m still not sure of as the VM was still up but it just refused to keep on serving web pages, including all the funky admin tools my PHPMyAdmin and Webmin. It was around this time I found myself in possession of a shiny new VPS that was only hosting my fledgling app Lobaco so I figured a small time WordPress blog wouldn’t be too much for it to handle. Indeed it wasn’t and the blog has been steaming along on it ever since.
However the unfortunate internal server errors returned eventually and whilst I was able to get around them with the trusty old reboot a couple times they became more persistent until I eventually couldn’t get rid of them. After digging around in the event logs for a while I eventually stumbled across references to php_wincache.dll which upon googling lead me to posts like these, showing I wasn’t alone in this internal server error hell. Disabling the plugin fixed the problem and all was well with the world. Of course many months later I found myself trying to optimize my blog again and I started looking at the things I had removed in order to keep this thing up and running.
The first was the caching plug-ins which are unequivocally the best thing for performance on a dynamic PHP site. The vast majority of WordPress caching plug-ins don’t play nice with Windows as they make the assumption they’re on Linux and attempt to write files in all sorts of whacky locations that simply don’t exist. WP-SuperCache, although still suffering from some Linux based assumptions, can be wrangled into working properly with IIS and has been doing so for the past couple months. I also found that WinCache had been updated since I had unceremoniously removed it from my php.ini file so I decided to give it another try. Again everything was rosy for a time, that was until last weekend.
I fired up my blog on Saturday to find the home page coming up fine but I was logged out for some reason. This happens from time to time so I wasn’t worried but trying to login left me with the dreaded internal server 500 error. Poking around it looked like any non-cached page was failing meaning the majority of my site was unavailable. The event logs showed the dreaded WinCache dll failing again and disabling it brought my website back around again. It seems, at least for now, that I’ll have to give WinCache a miss as the last update to it was almost 3 months ago and its past performance has led me to believe that it’s not entirely stable.
So if you’re crazy like me, trying to run WordPress on IIS and all, and you’re WordPress blog seems to take a dive more often than not make sure to get rid of WinCache at least until they get their act together. I haven’t delved into my previous VMs to see if it was the culprit back then but my most recent set of problems can be traced directly back to WinCache wrecking havoc by attempting to cache PHP objects and if this post can save 1 person the headache of trying to track it down I’ll consider it a huge success.