TOPIC: FASTHOSTS
A waiting game
20th August 2011Having been away every weekend in July, I was looking forward to a quiet one at home to start August. However, there was a problem with one of my websites hosted by Fasthosts that was set to occupy me for the weekend and a few weekday evenings afterwards.
Since the issue appeared to be slow site response, I followed advice given to me by second line support when this website displayed the same type of behaviour: upgrade from Apache 1.3 to 2.2 using the control panel. Unfortunately for me, that didn't work smoothly at all and there seemed to be serious file loss as a result. Raising a ticket with the support desk only got me the answer that I had to wait for completion, and I now have come to the conclusion that the migration process may have got stuck somewhere along the way. Maybe another ticket is in order.
Several factors contributed to the waiting period referenced in the post title. First, support response times for budget hosting packages are notably slow, which makes me question whether higher-profile websites receive better service. Second, restoring websites via FTP consumes significant time, as does rebuilding and repopulating databases. Third, DNS configuration changes also introduce delays.
In retrospect, these time demands might be reduced through various approaches. Phone support could prove faster than email tickets, unless during major incidents, like the security changeover that left numerous Fasthosts users waiting for hours one night. However, phone support isn't a universal solution, as we've known since those cautionary tales began circulating in the mid-1990's.
Regular backups would streamline restoration processes. While my existing backups were adequate, they weren't comprehensive, necessitating additional work later. As for DNS changes, more frequent PC restarts would help detect propagation sooner, a lesson I will remember despite having no immediate plans to relocate websites. Ultimately, accelerating DNS propagation makes a substantial difference in minimizing downtime.
While awaiting a response from Fasthosts, I began to ponder the idea of using an alternative provider. Perusal of the latest digital edition of .Net (I now subscribe to the non-paper edition to cut down on the clutter caused by having paper copies about the place) ensued before I decided to investigate the option of using Webfusion. Having decided to stick with shared hosting, I gave their Unlimited Linux option a go. For someone accustomed to monthly billing, it was unusual to see annual biannual and triannual payment schemes too. Because the first of these appears to be the default option, a little care and attention is needed if you want something else. Also, Webfusion offers a sliding scale pricing model: the longer your commitment period, the lower your monthly hosting cost becomes; it is a pricing structure designed to encourage longer-term subscriptions.
Once the account was set up, I added a database and set to the long process of uploading files from my local development site using FileZilla. Having got a MySQL backup from the Fasthosts site, I used the provided PhpMyAdmin interface to upload the data in a piecemeal manner without exceeding the 8 MB file size limitation. It isn't possible to connect remotely to the MySQL server using the likes of MySQL Administrator, while SSH is another connection option that isn't available. There were some questions for the support people along the way; the first of these got a timely answer, though later ones took longer before I got an answer. Still, getting advice on the address of the test website was a big help while I was sorting out the DNS changeover.
Regarding domain setup, it required considerable effort and searching through Webfusion's FAQ's before I succeeded. Initially, I attempted to use name servers mentioned in an article, but this approach failed to achieve my goal. The effects might have been noticed sooner had I rebooted my PC earlier, though this didn't occur to me at the time. Ultimately, I reverted to using my domain provider's name servers and configured them with the necessary information. This solution successfully brought my website back online, allowing me to address any remaining issues.
With the site essentially operating again, it was time to iron out the rough edges. The biggest of these was that MOD_REWRITE doesn't seem to work the same on the Webfusion server like it does on the Fasthosts ones. This meant that I needed to use the SCRIPT_URI CGI variable instead of PATH_INFO to keep using clean URL's for a PHP-powered photo gallery that I have. It took me a while to figure that out, and only to feel much better when I managed to get the results that I needed. However, I also took the chance to tidy up site addresses with redirections in my .htaccess file in an attempt to ensure that I lost no regular readers, something that I seem to have achieved with some success because one such visitor later commented on a new entry in the outdoors blog.
Once any remaining missing images were instated or references to them removed, it was then time to do a full backup for the sake of safety. The first of these activities was yet another time consumer, while the second didn't take so long, which is just as well given how important it is to have frequent backups. Hopefully, though, the relocated site's performance continues to be as solid as it is now.
The question as to what to do with the Fasthosts webspace remains outstanding. Currently, they are offering free upgrades to existing hosting packages for an annual commitment. After my recent experience, I cannot say that I'm so sure about going down that route. In fact, the observation leaves me wondering if instating that very extension was the cause of breaking my site. All in all, what happened to that Fasthosts website wasn't the greatest of experiences, while the service offered by Webfusion is rock solid thus far. Although I question whether Fasthosts' service quality has declined from its previous standards, I remain open to reassessing my opinion as I observe their performance over time.
Are ten seconds enough?
27th April 2009Fasthosts, the hosting provider for what you find here, has, in their wisdom, decided to limit the execution time for ASP scripts to 15 seconds and 10 seconds for any others. I haven't used Perl sufficiently in this shared hosting set up to determine how that is affected. In contrast, I can share my experiences on the PHP side and you may have noticed occasional glitches. They have also disabled the set_time_limit PHP function, so you cannot easily address the matter yourself where you need to do it. You almost get the feeling that they don't trust the abilities, actions and oversight of their users. Personally, I reckon that the ten-second limit is too short and that something of the order of 20 or 30 seconds would be better. If it all gets too restrictive, I suppose that there are other providers, though I think that I would avoid resellers after a previous less than glorious experience. There's the dedicated server option too if I was feeling flush, not so likely given the economic times in which we live.
Setting up Quanta Plus to edit files on your web server
3rd December 2007On Saturday, my hillwalking and photo gallery website suffered an outage thanks to Fasthosts, the site's hosting provider, having a security breach and deciding to change all my passwords. While I won't bore you with the details here, I had to change the password for my MySQL database from their unmemorable suggestion and hence the configuration file for the hillwalking blog. To accomplish this, I set up Quanta Plus to edit the requisite file on the server itself. That was achieved by creating a new project, setting the protocol as FTP and completing the details in the wizard, all relatively straightforward stuff. Since I have a habit of doing this from Dreamweaver, it's nice to see that an open source alternative provides the same sort of functionality.
