The Limits of Shared Hosting

Have you ever wondered which is the real difference among different offerings besides the fact that your applications run on a shared server? In fact, most of the times, this seems to be a tricky question because most service providers describe the boundaries and limits of their services based on the following common parameters:

• The resource type and quota: storage, bandwidth, mail boxes, mail lists, FTP accounts, database instances, etc.
• The underlying platform: Windows (IIS/Apache) or Linux (Apache) under whichever version.
• The amount of run-time services for your applications: .NET, PHP, Ruby, Perl, Python, Node.js, CGI/FastCGI, etc.
• The amount of libraries and components that are available to your applications.
• A library of pre-assembled web applications: CMSs, blogs, wikis, forums, ticketing systems, e-commerce sites, etc.
• Additional tools/services: web control panel, web analytics, SEO Tools, backup, additional security services (Anti-spam, SSL, etc.), version control, payment services, etc.
• And, of course, the degree of server sharing with other digital neighbors.

And, many times, the resources available allow us to deploy more than one application and, of course, we can’t figure out how much computing power we can use regardless how heavy our applications really are. But, as you are guessing, these computing power limits really exist and, of course, how much computing power our applications require, really matters.

If you think it twice, it makes sense that bigger hosting plans cost more money … 😉

So, which are those limits?

To be honest, different hosting providers might apply additional or different approaches. But, anyway, the bottom line is the same: your computing capacity is limited.

A very simple, effective and common way of achieving this is applying limits on two parameters that can be found on most run-time Application Hosts:

• Maximum Execution Time.
• Maximum Memory Limit for your Application.

Usually, each tenant (user) on a shared hosting server has its own run-time Application Host and these two parameters affect individually to each of the Application Host instances that are running on a given server.

On PHP, this two settings can be found on the php.ini file under the following properties:

• max_execution_time
• memory_limit

If you take a look to the output of the phpinfo() function, you will see many other parameters that could be used to cap your computing power.

In fact, it is always good to know that your hoster has plenty of alternatives to achieve this goal. Just to name a few:

• Additional Application Host parameters.
• Application Server settings. For example, in IIS they can control each Application Pool at will: CPU Limit, Private memory usage, etc.
• Web Server directives: CPU and memory throttling, etc.
• OS Workload Management: Windows System Resource Manager, etc.
• Network Traffic Shaping policies.
• …

Anyway, the simpler, the better. And that is why it is very unlikely that you find these techniques on a shared hosting environment. At the end of the day, a hosting provider will usually implement those strategies that show up effective and manageable when working at scale.

And, what happens when you reach the limits?

The symptoms can be very diverse because they depend on the applications involved, the end-user concurrency degree, the overall technological and/or behavioral context, etc. Here, though, you have a list of some of the most common ones:

• The server returns HTTP errors. The most common ones belong to the 5xx family of errors.
• The server returns a blank page.
• Very slow response time from the server. If you experiment different response times at different moments of the day, week or month, it can also be a meaningful symptom.
• Partial render of the page (i.e. missing images/objects, CSS styles don’t get applied, etc.)
• Run-time, and may be random, JavaScript errors.
• Unresponsive page actions (i.e. when you click on an actionable object, nothing happens).
• …

Ok, and how do I figure out that I am reaching them?

Good question. Your applications are always exposed to the public and you may be missing the timeframe where the nightmare happens.

Fortunately, whenever you are far away from your limits, everything is very simple: nothing works or the application is mostly unusable. For example, if you are running your own blog, you will notice immediately that you can’t even work through the administration interface.

For regular maintenance of your computing power limits, though, you can track and control your application behavior with traditional tools and techniques. For example:

1. You can use any web server log analysis tool, such as Piwik or AWStats, to identify any HTTP errors your site might be generating.
2. You can use Piwik or Google Analytics to control the average Page Download/Load Time.
3. Your Hosting Provider might offer you these tools as part of your service. For example, in my case, I have access to SmarterTools SmarterStats, which is perfect for this job.
4. You can also subscribe to one cloud-based web monitoring servicesto complement your view. Some of them offer free plans that can be enough for non-professional purposes.In this case you should remember a couple of things. First, these services add some stress to your site depending on the frequency and depth of the tests that will get executed. So, don’t be too aggressive: in the end, we are talking about Shared Hosting, isn’t it? ;-). And, second, they will also introduce some “noise” in your web analytics reports.
5. Dump the technical details of your environmentand analyze them carefully looking for potential memory or execution time limits.Each platform has its own method, but, in a PHP environment, for example, you should look to the output of the phpinfo() function. Just in case you’ve never seen it, just have a look to one of the many examples that you will find publicly available around the web ;-).

If you happen to deal with the WordPress ecosystem you can also try the following:

1. Install a plug-in that shows you the amount of resources available: WP Memory Usage or WP System Health.
2. Review the code on your wp-config.phpfile looking for entries like these:

   define('WP_MEMORY_LIMIT', '64M');
   ...
   ini_set('memory_limit', '64M');
   ...

This is, obviously, the WordPress case. Just remember that similar plug-ins or configuration settings might exist under the ecosystem of your (open source?) application.

Is there anything we can do to mitigate this situation?

Of course, there are! :-D. Here you have, at least, 12 ways of boosting your Shared Hosting experience:

1. Take care of your database with a regular maintenance plan: update statistics, indexes, compact tables, etc. Actually, if your application has some sort of server-side backup plug-in it is very likely that the backup process already include some of these actions.
2. Take care of search engine bots with nice policies (robots.txt) and site maps. These simple measures will prevent any waste of resources when your site is getting indexed and will contribute to better achieve ratings on search engines too.Remember that you can build and update your site map automatically. For example, if you are using WordPress, there are many plug-ins that can do the job very nicely.
3. Implement caching and minification. These tools are, in fact, among the most effective ones. But it may require you to manually warm-up your local cache every time you update code or content that gets delivered to end users. Fortunately, it is very easy to accomplish this with any web spider tool like HTTrack.As we are on a Shared Hosting environment, we cannot expect any sort of transparent caching services. So, in this scenario, each application has to implement its own caching mechanism.In my case, I am using W3 Total Cache for my blog. This plug-in also opens the door to leverage, potentially (though very unlikely on a Shared Hosting environment), distributed caching or CDN Services from a number of Service Providers.
4. When possible, limit the number of items that get published each time and encourage search and navigation. This would help reducing the Average Page Download Timewhich, generally speaking, usually contributes to reduce server load.This can be a tricky topic, because, for example, your application might require large and long-living session objects and not all the application servers or run-times handle them the same way. This could, potentially, be a little nightmare on a Shared Hosting environment.Anyway, lighter presentations of your content such a mobile versionof your site or allowing full RSS feeds may not include all the elements of your regular home page or even require less plug-ins to get rendered.For the same reasons, the use of applications with AJAX UIs or with “fat” clients that leverage eventual REST, SOAP or XML-RPC services published by your application can also be helpful. This is the case, for example, of Windows Live Writer or some native mobile applications.
5. Get rid of the dirt! (I). Deactivate/Uninstall unnecessary themes, plug-ins, etc. that introduce run-time load.
6. Get rid of the dirt! (II). Keep installation cleanof logs, old files, old versions or unneeded applications, etc.This is not only important from a security point of view, but also will help reduce the load of your server-side backup strategy and prevent potential failures when backup processes run under your Shared Hosting account.You might be thinking that you can always use a client-side strategy (downloading a copy of your site by FTP, for example). If this is enough for you, that’s perfect. Unfortunately, this is not always a practical approach. In fact, that is my case: I am not always at home, but I need to be sure that backups run timely and flawlesslyin an automated way.Unfortunately, building ZIP files it is a heavy operation: the bigger the file set, the heavier. Therefore, any contribution to maintain the number of files on your backup jobs between reasonable margins will be definitely good.
7. Get rid of the dirt! (III). Group secondary items under the same folder (i.e. test and developments under /lab/, or backup arhives under /bak/).You can now forbid anonymous navigation on whole folder trees and exclude them easily from your server-side backup processes.
8. Forbid anonymous navigation when possible or reasonable. This simple measure will prevent any waste of resources coming from unwanted visitors.
9. Implement basic security measures that help to preserve your computing resources. For example, if you are running a blog, you can use: CAPTCHAS, Anti-spam filters, comment moderation, etc.
10. Take advantage of remote cloud services whose content get composed on the client side. This way, you can publish it without consuming resources from your hosting account.You can embed almost any content typefrom remote services these days: photos (Flickr, …), videos (YouTube, Vimeo, …), maps (Google/Bing maps), files for download (Box.net, CodePlex, …), basic office applications (Google Docs, Office WebApps, …), etc.There are plenty of plug-ins for doing these things very easily on many applications. On WordPress, for example, you can find SlideDeck, TubePress and Photonic Gallery just to name a few. Your application might also support the oEmbedopen standard as an additional way of achieving the same goal. So, it might worth some research ;-).Therefore, generally speaking, this strategy will not only increase your overall performance but also contribute positively to reduce your server load and, as an interesting side effect, the success of your server-side backup processes.
11. Keep your web applications and associated plug-ins up to date. This should fix known problems and solve potential performance issues that might be impacting your computing resource quota.Of course, right before updating, you should guarantee yourself a rollback just in case something goes wrong. That’s one of the reasons why backups are so important.
12. Finally, if you have implemented most of these ideas but, despite your efforts, you are reaching your computing power limits, it might mean one of two things. The obvious one is that you are running a successful site with a growing number of visitors. Congratulations! ;-). In this case, you should start considering an upgrade to a more powerful hosting plan.The other scenario is not so pleasant. Your hoster might be doing a poor job managing your service. If Customer Service doesn’t meet your expectations too, you should start thinking of migrating to a different hosting provider. Fortunately, this market is highly competitive and it is very easy to find alternatives which will offer good quality of service at reasonable price/functionality ratios.

Final thoughts …

Remember that you can always design your environment so that you can leverage the capabilities and tools found on one application to help you out with your whole Shared Hosting environment. For example, if your applications share the same database instance, you can use WordPress BackWPup to handle backups for all of them. Just spend some time analyzing your context and you will figure out a combination that takes the most from each application strengths while minimizing its weaknesses :-).

I would like to share with you one last thought about what I’ve learned through my years with diverse Hosting Service Providers: Don’t get fooled by price, huge amount of storage, libraries or lots of features, … This is great, the more competition, the better for us, users. But:

1. What really matters is your time! Unfortunately, problems usually come when you don’t have it. So, when selecting a Service Provider, do some research on the web looking for positive feedback on quality of service, customer satisfaction and technical support. When a Service Provider is good on these topics is worth paying a little bit extra, if that happens to be the case.
2. “Too cheap” may mean that your computing power is too low to afford what you are trying to accomplish. Unfortunately, there are not immutable laws here and everyone looks great on its web site, doesn't it?. Therefore, just take your time to verify it yourself: if you have a free trial or a cheap entry price, you can definitely give it a try and learn from the experience. You might uncover nice opportunities just by trying! :-).

Don’t be afraid of changing. What used to be a good deal years or months ago, might not be the case today. For example, Shared Hosting will grow in computing power with time and, eventually, some Service Providers and Applications will start offering elastic capabilities so that you can manage your computing power on-demand having to move to a dedicated environment.

Well, that’s all folks! ;-). I wish I have helped you in any way. Now it is your turn! What’s your experience? What do you think? I would love to hear your feedback 🙂

Image sources: http://bit.ly/Px9ugN