Facing Magento with New Relic

This is a guest post by Dyan de Rochemont, lead Magento developer at Bold Commerce, a Magento-dedicated e-commerce company based in Amsterdam, The Netherlands. He specializes in Magento performance, architecture, customizations and security.

Magento LogoA few months ago, a Dutch wine company faced tough performance and availability problems with their Magento CE webshop. Not being a client of Bold Commerce at that time, they reached out to us for assistance and asked us to assess the situation and possibly provide a solution. Their platform had been performing unacceptably bad for some time: 5-8 second pageloads, with the shop going offline completely when it hit anything near a double-digit amount of concurrent users. Even a migration from a shared hosting environment to a full-blown dedicated server hadn’t offered any solace.

We’ve had experience with such behavior in the past, and more often times than not, with the Magento API to blame. Although out-of-the-box Magento is not quite top of its class when it comes to performance, we suspected this could be true for this particular case as well, with Magento being connected to a Navision (now Microsoft Dynamics NAV) ERP through the API.

Tools of the trade

After having consulted some of the resources and tools commonly available for Magento debugging, we quickly resorted to New Relic as our weapon of choice. We’ve been familiar with it for quite some time, as New Relic has a partnership with our hosting partner Byte.nl and they ship this Swiss army knife with every Magento hosting package by default. In the past, we’ve been able to successfully deploy New Relic and use its in-depth analyses to determine bottlenecks and resolve them in favor of performance and stability. Pains such as slow database queries, clogged tables, bad coding practices and badly performing Magento extensions turn up pretty easily.

We installed it on the Linux-based webserver and could almost instantly see some curious and trippy behavior.

Mechanical vehicle conspiracies

On typical MVC-based platforms, all requests, apart for physically existing files, are being rewritten and routed through a central hub (such as /index.php), for example, with mod_rewrite through a .htaccess file. Based on the request path, the hub determines the appropriate controller through router-matching and lets it handle the request. Certain paths that contain static content, such as images, javascript and stylesheets, are usually being excluded from being rewritten as such.

The part responsible for this behavior in a typical Magento installation is:

RewriteEngine on

RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php [L]

These rules allow for requests that are not a physically existing directory or file, and do not reside in /media, /skin, or /js, to be routed through index.php.

With New Relic, we quickly learned that, through a misconfiguration in Apache, the line that excludes the media, skin and js dirs was being ignored completely, ending up with every request that’s not a physically existing file being routed through Magento; thus generating a 404 through Magento, and not on webserver.

 A dollar for every penny

Those of you familiar with Magento know that every call to Magento is an expensive one, being the complex framework that it is. Based on Zend Framework, it takes abstraction to a whole new level with Magento CE having no file shy of 12K in its repository.

With most of the pages of this particular shop having 4-10 unfortunate, incorrect references to files in either the /skin or /media directories (for which Apache normally would generate a 404 itself), each page request unfolded into a repetition of multiple calls to Magento, eventually serving a 404. Imagine the massacre caused by crawlers/spiders.

With New Relic, we were able to quickly diagnose and address a persistent problem that needed acute acting. It allows for quick diagnoses, not just incidentally but on a frequent, preemptive base. Furthermore, it facilitates a way to prioritize things in terms of performance: it’s a breeze to determine the problem next in line and be able to elevate to the next level.

This post was written by a guest contributor. Please see their biographical details at the top of the post above. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!