[ LABORATORY NOTES ]

Last week, I posted about my experiences with Magento as a product. Today, I’d like to cover some of the interesting performance issues I’ve experienced and the ways I’ve worked around them.

I’ve published Magento in a few different environments, some for development (testing), others for production (live!).

Geeks will want to know that having root (full administrative control of the server) certainly helps, but is not required. Mostly, the joy of root in this situation is that it makes creating backups (via tar) and updating (which means doing some chmod dances) much simpler. Obviously, if you have an SSH user, you can do these things as well. However, if you can live with having your files 777, it’s really not that big of a deal. Magento is big, so backing up via FTP will take a long time, but it’s hardly impossible.

My preferred environment is a LAMP (Linux/Apache/MySQL/PHP) stack where I have root. I’ve deployed several development models and a few production models this way, and they worked like a dream. I have deployed Magento on MAMP (the app), MAMP (MacOSX/Apache/MySQL/PHP compiled, not the app) and WAMP (WindowsXP or Windows Server 2008/Apache/MySQL/PHP for various tests and development. This was less satisfactory, but worked. The MAMP application really didn’t like it, and required a bit of tweaking to get it going, but I don’t see MAMP as a viable production option anyway. (I’ve never had reason to try MAMP Pro.) Most recently I installed it in a shared LAMP server with a Plesk control panel. There were a few minor challenges here, but I was able to work with tech support at the host to get them resolved quickly.

For the average non-geek, it’s probably helpful to know that a LAMP stack is an extremely common shared hosting environment. Because it is inexpensive to set up and stable (low maintenance) almost every hosting company offers this package, and it is quite often their lowest priced option! So getting Magento to run on your site should not be a difficult task for a developer familiar with Magento.

I’ll admit that the first couple of instances of Magento I installed, I was very disappointed in how SLOW it seemed. It was as though the big giant toolbox was just too darn heavy and slowed everything down. Adding new products was a chore and surfing the site was a less-than-ideal situation. But then I discovered a few little tricks to speed things up. If you are installing Magento for the first time, you might find this information helpful.

Because Magento compiles each pages from dozes of files on each page call, performance with Magento has to do with both the environment its hosted on and with caching options. As I noted before, you want caching off during development. But once that puppy is ready for production, turning caching back on will dramatically improve time to serve pages. There are also options to cache javascript and css, like Fooman Speedster, which make things even faster. Of course, the mySQL query speed is going to matter, but the Mage engine seems to do a pretty good job of compiling requests. There is a developer option available to display the performance stats for each page draw in the page footer which can be helpful to tweak and optimize certain things. there is much to learn and try when tweaking for performance, and a good place to start learning is here: Magento performance and optimization group .

After receiving a scary email from ZenCart yesterday, I’m even more inclined to choose Magento for an out-of-the-box good solution that is very customizable. If properly done, it can be customized heavily and stay upgradable. I’m looking forward to my next installation, which should be happening in the next month!

PS: Some readers found this information daunting. This is why Magento works best when implemented by someone with development experience. At the Mad Science Department, we enjoy developing Magento solutions and handling all the scary bits so that our client agencies don’t have to! We are kind of…um…Mad that way.