Just deployed a new Magento site? Or migrated to a new host?
Here are some things you should before you launch…
- Magento base code may not include the latest security patches! Check the download page for the latest and apply them. For example, Community 188.8.131.52 is still vulnerable to Shoplift out of the box.
- Change your Admin path – anything other than the default /admin, to make your Magento backend harder to find or brute-force. This is usually configured in your app/etc/local.xml.
... <admin> <routers> <adminhtml> <args> <frontName><![CDATA[something_unique]]></frontName> </args> </adminhtml> </routers> </admin> </config>
- Admin password: if you were using “admin123” while in development, now is a good time to change it.
- File permissions: tend to get overlooked in development. Here’s a handy guide on what they should be.
Magento caches are often disabled during development, but in production it’s essential that they’re all ON. In the Dashboard, go to System > Cache Management and enable them. Related article: Magento Full Page Cache
This relates to the four log_* tables in the database. They’re a bit like access logs which are not rotated by default – this is bad because it bloats your database, wastes your InnoDB buffer, and makes database backups more cumbersome.
Go to System > Configuration > System > Log Cleaning and enable it. The default 30-day retention should be fine.
The Magento cron job should be run every five minutes. Top tip: run cron.sh instead of cron.php. The shell script first checks it’s not already running, then runs the PHP, preventing overlaps.
*/5 * * * * /bin/sh /path/to/docroot/cron.sh
As of Magento 1.9.1, the cron job is responsible for sending customer email so it’s more important than ever.
If you are using Community Edition, indexing may not be a problem to start with, but one day it’s going to cause issues. Here’s my advice on how to configure Magento indexing.
Death, taxes, and Magento 503s. Even a well tuned Magento application infrastructure can be complex and one day something will break. Or maybe we’re talking planned maintenance; installing a new extension for example. Here’s a great tutorial on customising your Magento error pages. It’s best to get this done early on, so you’re ready for the unexpected.
Top tip: Other reverse proxies like Load Balancers and Varnish (if using) will probably show their own 503 page when something is broken. Talk to your hosting provider about modifying these – default error pages don’t inspire confidence in your brand.
The goal here is a nice customer experience even when something is broken. Make sure there’s a phone number or email address at the very least. Including a discount code will encourage customers to come back and buy later.
If time allows, the last thing to do before launch is a load or performance test to get insight into what your new solution can really do. It’s best to do that before you have real world traffic, otherwise load testing is basically DOS’ing yourself. Load testing is also likely to show up areas for config optimisation/performance, which is always a good thing.
Don’t: rely on tools like siege, or services like loader.io and blitz.io. They can be extremely useful of course, but only if you are able to interpret the results properly. Unless you have a deep understanding of HTTP protocol headers, cookies, unique session IDs, these tools probably won’t help you all that much.
Do: get it done professionally. You need a test that can mimic actual human user journeys, and repeat them on a massive scale. jMeter is great, but doing it right can be complicated and very time consuming. I would argue this is best left to professionals who do just that. Not cheap, but a necessary investment for your website’s future. Your hosting provider might offer professional load testing services, or refer you to someone who can. Soasta are excellent.