5 Questions to ask before selecting a Magento Managed Hosting Provider
5 Questions to ask your Magento Managed Service Provider
- Does the managed provider help you with setup of a CDN?
Content Delivery Networks or CDN is the best way to get a boost of your page load time. A CDN takes away the load on your server by caching commonly used files that do not change frequently. Such files include css, js and image files. For a Magento store, images constitute a large amount of time and bandwidth of a page.
Large CDNs have an additional advantage of having multiple end points or servers near your customers. This reduces latency and images tend to appear immediately.
The good news is that CDNs are now a commodity – they are aggressively priced with some large CDNs having unlimited free plans.
The only catch is that you need to “invalidate” or “purge” cached content from the CDN if you were to change the same file on the live server. Until automated, this procedure can be a burden.
Your Magento Managed Hosting Provider should provide you with practical and complete options for a real CDNs, including help in configuring your Magento site to use your selection - Does the provider have a disaster recovery plan – not just a backup?
Backup is as good as the restore process.
Yes! Just having backup is a essential but not sufficient.
If your site were to be hit by a disaster, how would you be able to bring up your site on another server? Would all services start as desired?
Funnily we have seen many magento servers do not come back to full service on a simple reboot, far less a disaster.
Moreover, backups should be taken “off-site” – not within the same zone or provider you currently have.
And your Managed Magento Hosting provider should give you a written disaster recovery plan based on different types of scenarios and that you can put into motion if the time arises. - Does your provider regularly evaluate and tune for optimal cache performance?
Magento site performance is quite often driven by the condition of its various caches. Caches store results in RAM vs either on disk or having to compute the results. As a quick look at the Cache Management page on Magento’s admin panel shows there are many application level caches. In addition, mysql stores query results in a in-memory cache, however requires the cache to be sized and enabled in a configuration file. The php code can be stored in a opcode cache in the php server. This also requires memory allocation and enablement.
Since no two magento stores are the same, there is no standard configuration. It requires observation and tuning.
Your Magento Managed Hosting provider should give you information and tune the cache, possibly even advising you with server sizing in the process. - What scalability plan has the provider made for you?
As hits increase, it may be required for your site to scale. But, how will you even know the time has come?
In todays world, a slowdown of your Magento site is equivalent of downtime. Consider this – each drop of a second in your load time results in drop of visitors.
If traffic spurted due to a online or offline ad, how would you know the server capacity needed to handle the spurt? Do you need autoscaling and loadbalancing technologies?
Your Magento Managed Service provider should be on your side in advising - Do you know the deliverability of your transactional emails?
An eCommerce site sends many emails – new user registration, password change, order confirmation, abandoned cart. These emails need high rate of deliverability. If emails are directly delivered from the host, there are 2 problems - It is not known which emails are delivered and which are not. amd secondly mail servers are constantly upgrading their needs of the senders ability to send, resulting in increased non deliverabilityMany services are available to handle such emails – Amazon SES, Mandrill, Sendgrid to name a few. Each give a varying level of granularity of reports and pricing plans to support your volume.Most of these services have Magento Plugins, some premium. However, a email plugin will attempt to send the email “inline” – for example the order email is sent while the customer is waiting for the success page. A better solution is to send the email to the local system queue, and let the system process the queue by sending the email to the transaction email provider.Your Managed Magento Service provider should be able to configure your server’s email system to use your chosen transaction email provider?