Traffic profile by page

I’ve been looking at the profile of our traffic. On our biggest site, the top 50 pages account for more than 50% of our traffic. Across all four sites, our top 100 pages account for 50% of total pageviews.

Getting this data out of Google Analytics was easy. To start with I went to the Content > Site Content > Pages report, switched the view to percentage, and added the percentages for our top 10 then top 50 pages with a calculator.

To get data for all our sites, I used this trick to export the data for all our sites. I had to use the old interface to do this, then Content > Top Content. I combined all the data into a single sheet in LibreOffice Calc, added a row for the site domain and one for the total pageviews on that site. That allowed me to graph percentage of total traffic for our most popular pages.

I graphed our traffic with a log scale, and it looks a lot like the graphs from the Long Tail.

Our pages are around 10K. So a quick calculation suggests that (allowing 100% extra for Varnish overhead) we could serve 50% of our total traffic from 2MiB of cached data, or 80% of our traffic from 12.5MiB (640 pages, 20KiB per page). That puts an interesting spin on the idea of using a varnish cache.

I wonder how our traffic profile compares to that of other sites. I’d imagine some sites are more niche, with less traffic in the “head” and more in the “tail”. In those cases, caching might provide less of a performance boost.

This also got me thinking about benchmarking cache performance. I’ll think about it and write more in a later post.

Update: Another couple of perspectives. We have fewer than 500 pages out of a total 12k which get more than a 100 pageviews per month (3 per day). If we can serve 80% of traffic from 12.5MiB of cached data, in economic terms that’s £7/month!

Xeround eu-west-1a from Rackspace UK

I love the idea of Xeround‘s offering. A fully managed, scalable, pay for what you use, MySQL compatible cloud based database. It’s a great pitch. Zero configuration, massive concurrency, and totally compatible with Magento.

Xeround launched on Rackspace in the US with plans, but no date, to launch in the UK. Their only current EU Presence is Amazon’s eu-west-1a region. I ran some benchmarks to compare performance between a Rackspace cloud server running MySQL and Xeround in Ireland. The ping times tell the story.

ping -c4
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=50 time=19.1 ms
64 bytes from ( icmp_req=2 ttl=50 time=18.7 ms
64 bytes from ( icmp_req=3 ttl=50 time=18.7 ms
64 bytes from ( icmp_req=4 ttl=50 time=18.6 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 18.657/18.835/19.153/0.233 ms

ping -c4
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=53 time=16.1 ms
64 bytes from ( icmp_req=2 ttl=53 time=16.2 ms
64 bytes from ( icmp_req=3 ttl=53 time=16.2 ms
64 bytes from ( icmp_req=4 ttl=53 time=16.1 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 16.161/16.200/16.238/0.130 ms

ping -c4
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=53 time=12.5 ms
64 bytes from ( icmp_req=2 ttl=53 time=12.3 ms
64 bytes from ( icmp_req=3 ttl=53 time=12.4 ms
64 bytes from ( icmp_req=4 ttl=53 time=12.3 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 12.365/12.432/12.586/0.143 ms

ping -c4
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=64 time=0.317 ms
64 bytes from ( icmp_req=2 ttl=64 time=0.307 ms
64 bytes from ( icmp_req=3 ttl=64 time=0.300 ms
64 bytes from ( icmp_req=4 ttl=64 time=0.320 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.300/0.311/0.320/0.008 ms

ping -c4
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=64 time=0.340 ms
64 bytes from icmp_req=2 ttl=64 time=0.308 ms
64 bytes from icmp_req=3 ttl=64 time=0.333 ms
64 bytes from icmp_req=4 ttl=64 time=0.330 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.308/0.327/0.340/0.025 ms

Pretty pictures

The ping times actually tell the whole story, but before I tried that I ran the example dbench config, and it produced pretty pictures, which I’ll share now. The important thing to look at in these graphs is the scale along the left hand side. I ran tests on the internal and public IPs of the Rackspace cloud server and the three IPs made available for xeround.


Maybe it was a crazy idea from the beginning, but I think it was worth the couple of hours I put into testing the theory. When Xeround launch on Rackspace UK, I’ll be interested to compare it against our own MySQL server. Unfortunately, for the time being, it’s a non starter.

I did find it interesting that there was a noticeable difference between the different IPs to connect to xeround. I’m not sure what the cause of that is. It might simply be that the connection is unpredictable because it’s going across networks. Another reason to keep our database and web servers in the same place.

Benchmark details

I have no benchmarking experience, so my approach was quite primitive. I commissioned two Rackspace cloud servers. One to run the test with 512MB memory (benchie), one to host MySQL with 1024MB (benchdb). I downloaded dbench, installed php5-cli and php5-gd (for the pretty pics!) and then set up the example/config.php to connect to xeround and let it rip.

While that was running, I installed mysql-server on benchdb. I changed the bind_address to in my.cnf so MySQL would listen on all IPs. Other than that, I made no config changes from the default.

benchie was the Rackspace Ubuntu 11.04 image, benchdb the Ubuntu 10.04 LTS. I ran apt-get update / upgrade, created a new user, and otherwise left the machines stock.

Magento hosting providers

I’ve spent the last couple of days looking at various quotes for Magento hosting. Prices for managed, dedicated servers vary considerably. At the lower end on the price spectrum are ForLinux, who seem to have great Magento experience. Peer1 were mid range, and Rackspace were the top end.

There were a few other Magento specific offers in the mix, but they fell out because of professionalism issues. Quotes taking forever, being sloppy, unclear, or unresponsive (or in some cases rude) sales people. Bottom line, we’re buying peace of mind, not hardware, and that starts from the first interaction. If a company is too busy or insufficiently motivated to reply or send us quotes timeously, they take themselves out of the running.

ForLinux look like a great value, very responsive option. They have a cloud offering, but there’s no online pricing, and it’s not clear to me if they provide the cloud products themselves or provide a management service on top of AWS.

Peer1 have recently launched Zunicore, which is a highly configurable cloud service. It’s possible to increase memory or CPU without hard drive space, or vice versa. That’s an appealing option as it allows more careful tailoring of services required. For example, more memory and less disk for database servers, more disk less memory for static hosting, and so on. The Zunicore service launched last month and so it’s not fully battle tested at this point.

Rackspace have the most advanced cloud offering of all three. They offer servers (managed or unmanaged), load balancers, and cloud files linked to a CDN. It’s this breadth of offering that has me leaning towards Rackspace at the moment.

The idea of starting with a dedicated server backed by a management service, with the flexibility to add cloud servers for couchbase (memcache), reverse proxies, and so on, is very appealing. Plus, in theory, the ability to scale up resources for higher load times, and scale back after, is also an appealing idea.

In reality, I’m not sure how much difference this will make in practice. But having the option available is a significant factor in our decision.

Measuring web site speed

My first challenge in the quest for ultra high performance magento is to measure current performance. How fast does our site load? How long does it take from the moment a user clicks our link to the time they can see our web page?

There is no simple answer to this relatively simple question. There are some great tools that help to answer the question, but none of them are quite perfect. I’d like to get a regular snapshot of our page load times across a range of pages, taken at regular intervals. So far I’ve found a range of tools that will give me instant data on the page load time, only one that will check it regularly, and the slowest interval is every 20 minutes for $5 per check location per page per month. My research continues…

I found a great question on serverfault (via this) that linked to most of the monitoring services I could find. There’s a trove of information in there. The providers I looked at in some detail are:

We are already using the free tier on Pingdom to monitor uptime. One url gets hit every minute, free of charge, and notifications get sent if the site is down. For $10 a month, we can increase that to 5 urls, plus 50c/month for each url thereafter. I think that’s likely to be our most sensible option.


If there was a service that was 37 signals simple, checked that our site was online regularly, sent alerts, and monitored the site speed a few times a day, for $10 or $20 a month, I’d sign up immediately. Pingdom or Monitis looks like the closest thing.

Two categories of speed

Speed testing services seem to fall into two categories. Services like Pingdom’s monitoring track the time it takes to load the html page. Then browser tools give an indication of how long it takes to “render” the page in a browser. So the first is measuring straight server response time, the second trying to measure the user’s load time.

Personally, I’d like both to be measured and recorded regularly, I want all the data I can get, all the time! I haven’t yet found such a service, it seems like all the page load measurement tools are aimed at giving advice, and benchmarking, rather than ongoing monitoring.

There are lots of benchmarking tools around.


I’d forgotten about monitis while I was writing most of this. They offer the services I’m looking for, but the real stickler is the minimum frequency of every 20 minutes. I’d much rather than 10 pages on our site measured for speed every 4 hours, than 1 measured every 20 minutes. Under their pricing model the cost per page speed test is $5/month, every 20 minutes, per location.

Update, I just called Monitis and spoke to a very friendly chap who said they would make a custom plan for my requirements. Once I’m clear on how many pages I want to check and how often, I’ll send them a request for a quote.

Update: I forgot to include this link, I’m guessing this is the article that put site speed on many people’s radar.

Hello world!

Welcome to Pergento, a blog chronicling my adventures in pursuit of ultra high performance magento.

I’m engaging with my brother with the aim of radically improving the reliability and dramatically increasing the speed of his magento based ecommerce sites. I’ll share stories of my adventures as the journey unfolds. I hope to be able to share tales of what works, what doesn’t work, and most significantly, how the changes I make affect conversion. The goal of this whole exercise is to help drive higher revenue through magento powered sites.

Amazon and Google seem to both agree that page performance affects sales. I’ve seen the figure repeated from Amazon that a 100ms increase in page load times reduces sales by 1%. I’ll try to find a source for that. Likewise, I’ve read that increasing the speed of a site can dramatically boost search result placement. Again, I’ll try to find the references.

If you’d like to stay informed of the adventures, please subscribe to the feed, or sign up to receive email updates by clicking the “Follow” box in the bottom right hand corner.