Testing Magento admin performance
Whilst migrating a customer website, testing had shown a poor admin area performance. In order to rectify the issue, it was important to have a CLI tool available to repeatedly test specific URLs.
Testing the front-end is easy - you just use mage-perftest
- but testing the admin area is more difficult, as it requires authentication, form keys and hashed URLs.
That presents two options for testing,
- Test manually via a web browser
- Write a script to automate the process
The obvious choice was to go for option two.
Introducing mage-perftest-admin
The script just needed to take a list of admin URLs, perform a HTTP request and measure the time it took to execute. So I knocked up mage-perftest-admin.php
as a Magento shell script to do just this.
Usage
Download the CLI script and place it into your Magento ./shell
directory, then execute via command line,
cd /microcloud/domains/example/domains/example.com/http
wget -O shell/mage-perftest-admin.php https://raw.githubusercontent.com/sonassi/magestack-scripts/master/cli/mage-perftest-admin.php --no-check-certificate
php shell/mage-perftest-admin.php
mage-perftest-admin.php Usage:
mage-perftest-admin.php [url_match] [url_match] .. [url_match]
url_match A partial of the Magento admin URL you want to hit. The script uses this string to search
through the Magento admin navigation to find the appropriate URL.
You can pass as many URLs as you need to match, in my tests, I'd been given three specific URLs by the customer,
- system_config/index
- sales_order/index
- helpdesk_ticket/index
With these, running the test is as simple as this,
php shell/mage-perftest-admin.php 'system_config/index' 'sales_order/index' 'helpdesk_ticket/index'
[notice]: Creating admin user
[notice]: Creating session
[notice]: Logging in
[notice]: Login successful
[]: --
[results]: 1.724s system_config/index (Configuration / System / Magento Admin)
[results]: 0.571s sales_order/index (Orders / Sales / Magento Admin)
[results]: 0.648s helpdesk_ticket/index (Tickets / Magento Admin)
[]: --
[notice]: Deleted admin user
You'll see the script automatically creates an admin user for itself, creates a session whereby it can use the generated form_key
and admin URL hash to fetch the required resources; then it just looks over the URL partials, identifies a match, times the request and finally deletes the temporary admin user.
Problem solved
Now with an automated tool, I could get to finding what the bottleneck was - which, thanks to MageStack's powerful logging, I managed to track back to a blocking external CURL request (read more on "calling home") for a 3rd party extension.