Notes on this guide

This guide assumes you are a developer, or at least that you are using developer tools to do things. For instance, developers will prefer modman or composer to install extensions and use n98-magerun to manage shops. This might not be the only way of installing Aoe Profiler - there are definitely more ways. However, we believe Magento becomes really powerful if SSH is used for managing things. Also, Aoe Profiler is a great tool for analysing things, but it already requires a developers mind to actually interpret its results.

Installing the extension

The Aoe Profiler is available on GitHub with both a modman file and composer.json file. This means that there are various ways to install the extension (modman, composer, file copy) and we prefer the modman way.

The following assumes you have modman already up and running:

modman clone https://github.com/AOEpeople/Aoe_Profiler

After this, the Aoe_Profiler module is in place, but we want to make sure that the module is detected by the Magento configuration, so we flush the cache. Also, we make sure to run the setup-scripts - in the event that they are disallowed by default. For this, we make use of n98-magerun (or in our case an alias of this command magerun):

magerun cache:flush
magerun sys:setup:run

Setting up AOE Profiler

In previous versions you could simply enable the profiler in the backend. Current versions take a different approach: They require you to copy an XML configuration first and edit that to your needs. First of all, copy the sample file to its proper place:

cp var/aoe_profiler.xml.sample var/aoe_profiler.xml

Now you can edit the XML file to your needs. In my case, I simply wanted to troubleshoot every page in a local development environment, so I enabled the profiler for all pages:

<trigger>always</trigger>

After modifying the XML, the cache needs to be flushed again:

magerun cache:flush

Using the tool

Now if you browse to System > AOE Profiler, the overview should list some of your logged requests. You can click on one entry and this will open up the logged details for that request. The tree structure allows you to check which code segment takes up most of the loading. Things to look for:

• Loops in loads: For instance, when a collection is used to loop through products, you don't want to see a load() call for each of these products.
• Expensive events: When a specific observer takes too long to load, it might be that there is something bad going on.
• Long loading in weird places: For instance, one of the first steps is the load_cache entry and this should be fast. If this step takes long, something might be wrong with the caching mechanism.

Ofcourse there are many more things to look for, but you'll get the point.

Troubleshooting things

First of all, the usage of AOE Profiler assumes that you have properly installed the extension as well. When navigating to System > Configuration > Developer > Debug you should see the AOE options being listed. If not, the extension has not been installed properly.

More troublesome is it when the settings are there, but no logging takes place. When the installer has failed to run properly, the AOE Profiler database tables might not have been created properly - but this will cause SQL errors in either your frontend or backend. If this is not the case, something else is at play here:

• Double check whether your aoe_profiler.xml is properly configured.
• Within the System Configuration, check whether the option Max age of saved run data is set to something sensible. For instance, the value 1 does not make sense. This will remove entries after adding them. Instead, set this to something like 3600 (1 hour).
• Check your system.log also. I experienced one time that my MySQL max_allowed_packet was too low. In a development environment this should be something ridiculous high like 64M.

And ofcourse if this does not help, there is always a place on the web to ask for help.