Usually, we just  measure the performance of our customer’s applications and talk about it, but from time to time we have to set an example ourselves.

In the last couple of weeks, we increasingly felt that our blog isn’t loading fast enough to deliver a satisfying experience. You know that when you can feel it, it might be too late already. Additionally, SEO is about content and performance and our blog is an important marketing tool for us.

That’s why we went on a quest for improving the performance of our company’s WordPress-based blog. Our motto: “Don’t just complain about the lack of performance, do something about it!”

Step 0 – Measuring

Measuring is believing and so we started with this WebPageTest result. As you can see, the initial performance is bad, a lot of content is not properly cached, and rendering started after 2.6 sec. Time for some serious tuning.

Step 1 – Reading

Tuning requires you to know what to tune. Thus, we read the famous Best Practises for Speeding Up Your Web Site by Yahoo. A similar article by Google can be found here. If you deal with web site performance in any way, you should read this. We consider it mandatory for performance and web testers.

Step 2 – Wordfence

One of the first things we did was disabling Wordfence because we had the strange feeling that the performance degradation of the blog had started just recently – a couple of weeks ago, we’d installed Wordfence in response to the WordPress login probing attacks. Yes, the disabling made us faster: first byte time came down from 1.7 sec to 0.7 sec. This was awesome… but who wants to run WordPress without protection? So we tuned Wordfence and disabled the firewall and live traffic detection, basically just keeping the login security and scanning features.

Step 3 – JavaScript

So, what was next? We realized that Slimbox had an impact because of the MooTools library it used. Not really a huge impact, but the JavaScript held back the rendering and further loading. We picked wp-jquery-lightbox as a replacement which didn’t change that much but got a little faster; Jquery seems to be a little better optimized in terms of JavaScript performance and size.

We also updated the SyntaxHighlighter since we’d been using an older version that was no longer under active development. Yet no relevant change in performance here.

Step 4 – Thinking

That’s basically all you can do, provided that your content is okay (properly compressed images) and that you have a fairly small CSS file for your theme. Because changing the hoster, tuning the database, or even replacing the webserver is a little overkill for a low-traffic blog, we could only take the caching route next. You can go back to the Yahoo and Google article and check what is possible without starting to reinvent the wheel aka writing a new blog, changing the theme, rewriting all content…

Step 5a – WordPress Caching

When you look up tuning tips for WordPress, you immediately find W3 Total Cache and WP Super Cache. Based on our reading of reviews, Super Cache seemed to be a little easier to handle, so we tried that. Somehow we failed though: it didn’t do anything and the performance stayed the same. As it’s not that easy to use, we switched to W3 Total Cache.

Of course, Total Cache is overwhelming as well and it took a while for us to realize that it couldn’t save its settings due to the file system permission handling of our hoster. Thus, we updated the .htaccess files manually. Since we also pull content from our Piwik installation, we added some of the .htaccess settings there as well. These settings basically refer to  serving the content as cacheable to the browser, avoiding refetching as well as delivering the content compressed. CSS, JS, and HTML can be compressed quite well and so it’s recommended to run mod_deflate for reducing bandwidth consumption.

Step 5b – W3 Total Cache

We had to go through a lot of trial and error to get the performance where we wanted it. Total Cache offers so many options that we had to try over and over again. Don’t forget to measure the  settings several times since also the measurement tool can have a bad minute as well! Also, if you run on a shared hosting environment, you’re not alone and other traffic might influence your measurements.

Step 6 – Measuring Again

After all this was done, we measured the final performance. The first bytes now came in after 0.22 sec and rendering started after 0.7 sec. Wow! We’d begun with 1.7 and 2.6 sec!

Step 7 – Enjoying

This basically means that we improved the performance of our blog by factor 4 to 8! Google and Bing, feel invited to drop by and index our content! We hope that our visitors enjoy the improved performance as much as we do. If we wanted to further enhance it, we had to move to a better server that can be tuned by dealing with database and network settings on a lower level. However, this doesn’t make any sense right now, micro-tuning doesn’t do any good here.

Always keep in mind: you can only test what you know and understand. It is this knowledge that allows you to evaluate client performance the next time you have to test it, and it also provides useful feedback on how a problem can be solved or in which direction you have to look for a solution.

We’re looking forward to hearing about your client site performance tuning and measuring experiences. Please share your WordPress tuning and operational procedures as well. Happy performance blogging!

Powerful load and performance test tools don’t only retrieve pages of your website randomly with zillions of users at the same time, but they also cover realistic scenarios simulating the real-world user. It’s a given that they can deliver lots of useful information and plot interesting charts. To fully take advantage of these benefits, however, you need to be able to interpret this information and draw the right conclusions.

It is this need for the correct interpretation of test results, the mapping of all you see against actual application behavior that makes performance and load testing a non-trivial task. It requires much experience to decide on the right actions, make the right assumptions, or simply come up with a reasonable explanation of why something happened this way and not the other.

In today’s article, we’d like to present you a couple of charts displaying typical response time patterns, and discuss what they could indicate.

Disclaimer: Of course, the reasons for a certain behavior vary a lot, depending on your application and testing. However, as there’s no fixed manual for the interpretation of load testing charts, we want to provide you with a couple of basic guidelines to help you get better in interpreting them yourself and make the most out of your test results. Feel free to comment whether or not you agree with the ideas and explanations we come up with.

The Warm-up

These charts might indicate a system with a cold cache, for instance, when the system has just been started and the caches aren’t filled yet.

The basic characteristics of such a behavior are high response times in the beginning, followed by gradually lower response times until eventually a  certain degree of runtime stability is reached. This time frame is often referred to as the system’s warm-up period. Throughout this period, a couple of things can happen under the surface. If you know the system under test well, you’ll probably come up with the following: database and file system caches are filled, proxies learn about the data and store them, the system under test scales up because it sees traffic, page snippets are cached and so the computing overhead reduces… you name it.

Also keep in mind that it might be the testing process itself that causes such a response time profile. If the system is perfectly warmed up and you hit it, your sent traffic might be too uniform in the beginning. That being the case, randomization kicks in so that the traffic eventually distributes better over time. Furthermore, take into consideration that your load software and hardware are possibly not warmed up either.

The Caching

These charts depict either a typical cache clean or job patterns. In case of a cache clean, system-internal caches expire every half hour. If that’s not the case, the charts may indicate  a running background job draining power from the database or consuming lots of system bandwidth.

Both charts display the same test; however, this test has been executed for different time periods. While two spikes could signify a random event (despite the fact that the temporal distance of 30 minutes is suspicious), the longer test run seems to prove our first assumption: something is going on every half hour.

In any case, make sure that such a behavior is not produced by the test machines themselves, for example, because they’re busy writing or backing up data.

The Spiking

This is what we call a forest of spikes: many spikes that don’t seem to follow a comprehensible pattern; longer runtimes just occur occasionally, often caused by requests accessing certain data or URLs that produce long runtimes. To get behind that mystery, you have to dig into the results in more detail, find the calls behind the spikes, and derive a pattern based on the information you find. Often you’ll come across similar URLs, request parameters, or maybe response codes. Don’t forget any application logs you might have access to, such as web server, error, information, or debug logs. In a perfect world, your application under test offers the necessary tools to get to the bottom of this problem.

XLT lets you easily find this information. All test result data are accessible as CSV files that are quickly readable and documented. Feel free to work with this information and go beyond the scope of the reports available.

The worst outcome here is a non-identifiable pattern and no information on the server side as to what might have happened. In such a case, you have to repeat the test and narrow down your test setup later on to exclude as many variables as possible to find the cause. This is actually also a good time to ask for development or tech-ops support.

The 3rd-party Calls

The first chart is typical for issues with 3rd parties, especially in the field of e-commerce. We’re not talking about direct calls to 3rd parties here, such as analytics vendors or recommendation engines, but calls from one server to the other. Thus, the response time we see is the response time of two systems. Of course, it’s good to know the area where 3rd party calls typically happen, but you have to know the application under test anyway to test it efficiently. So when the final order steps start to act weird, you can easily narrow down the potential reasons.

The second chart looks more like the cache clean or expiration problem described above, but since you know the application, you also know that this area doesn’t use the typical caching logic but is highly dynamic instead. This means that the errors occurring every 50 minutes point into a different direction: as we know that 3rd parties are attached and called during shipping, we can conclude that the 3rd party failed on us.

Verdict

Knowing typical response time patterns helps you specify a certain problem so that you can give hints to the development or further shape the path of testing. If you can read charts and derive the right conclusions or at least know which questions you have to address, you’ll be ahead of the crowd. Be aware that knowledge on the system under test is very important – the production and measurement of a certain load doesn’t make much sense when you’re not able to actually interpret and explain what you’ve measured. Always remember: 42 is not a valid answer for everything.

According to onvab.com CyberMonday 2012 was the biggest buying and spending day ever!

Whether you are a fan of facts and figures or find such data rather boring – statistics published on dzone.com are really interesting: http://css.dzone.com/articles/black-friday-cyber-monday-2012

Short Summary

• Most of the shop seemed well prepared. Congratulations!
• Big players like Amazon and Apple came in with good results and obviously did their homework.
• Barnes & Noble should review their site really carefully: Up to 262 requests per page and about 10 seconds until a page was fully loaded – this upsets even patient customers.

Now imagine you run a retail site that doesn’t handle the increased traffic on such an important day. Without doubt this will bring revenue down big time, which leads to an upset CEO and rolling heads. Not to mention all the nasty comments on Twitter and Facebook.

But how to prepare for THE day?

Option 1

You could hire thousands of students (each of them owning a notebook, smartphone or tablet) and let them shop your site. If you want to repeat this scenario, you obviously have to pay them twice or three times or…

Option 2

You could automate common page flows using a good test automation tool and run load tests frequently, watch the trends, and really run your own BlackFriday before BlackFriday.

It´s up to you! Afraid we can’t help you with option 1…

XLT 4.2.0 delivers a large set of new and improved functionality.

The Script Developer has seen a lot of enhancements. Most noticeably is the support of variables now. You can store data from the web page, run calculations in JavaScript and store the result, and reuse all later. There is now the notion of global and local test data. So any data that applies to multiple test cases at the same time can be managed more easily now. Besides the already mentioned store commands, the Script Developer also permits assertion and wait commands for visibility, select and check boxes, as well as value attributes of an element.

Further usability improvements permit easier switching between projects and the execution of a single command in a test case for faster development. Test cases can now be run directly from the package tree without the need to open them first. The test data management has been completely reworked to simplify and speed up editing of data.

The load test engine supports a fully variable load test profile now. You can define any load pattern you want, such as a 24 hour test with peaks around noon and early afternoon, low traffic during night hours, slow ramp up in the morning and multiple load changes over the course of the day. Additionally the ramp up of arrival rates is now supported as well.

To speed up things and fully utilize the available connectivity, the upload to and the download from agents has been fully parallelized. Optionally you can adjust the desired concurrency. Also the timeout against agents can now be set.

The documentation layout as well as the report design have been redesigned to improve usability, make them visually more pleasant, and unify their appearance. Third party libraries used to deliver enhanced functionality have been upgraded to cover the latest browsers as well as UI trends.

Please see the detailed release notes for more information about new features, enhancements, and defect fixes.

Nice article about the advantages of CSS3 in terms of coding as well as download speed: CSS3 vs. CSS: A Speed Benchmark.

I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.

Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests. As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom to measure the loading times.

More…

Enjoy reading.

Just found two nice blog entries by Chaotic Java which explain nicely how Java Garbage Collection works. Might be still too much if you have never dealt with the topic before, but good reading for the others.

• Parallel and concurrent garbage collectors
• How does garbage collection work?

Enjoy reading.

Nati Shalom discusses in one of his latest blog entries the changes Google made to its page ranking algorithm and how it influences your Google page ranking.

Last month Google added Website speed to its site ranking algorithm: It’s Official: Google Now Counts Site Speed As A Ranking Factor… The rationale behind this move by Google is fairly straightforward:

Slow web sites lead to a poor user experience, and therefore should not appear at the top of the search list even if they contain relevant content.

This emphasizes once more the influence of performance on your daily business. A simple change to your site can now affect your entire page ranking and how users find your content. Continuous performance testing is now even more important than ever.

If you want to stay in touch with cutting-edge technology in terms of scalability of databases, high traffic sites, and large storage volumes, you should read these two articles on the new hstack.org blog.

Cosmin Lehene wrote two excellent articles on Adobe’s experiences with HBase: Why we’re using HBase: Part 1 and Why we’re using HBase: Part 2. Adobe needed a generic, real-time, structured data storage and processing system that could handle any data volume, with access times under 50ms, with no downtime and no data loss. The article goes into great detail about their experiences with HBase and their evaluation process, providing a “well reasoned impartial use case from a commercial user”. It talks about failure handling, availability, write performance, read performance, random reads, sequential scans, and consistency.

(via High Scalability)

In diesem Interview mit SEO marketing expert Amanda Watlington ist die Rede davon, dass Google die Geschwindigkeit einer Website in die Platzierung im Suchergebnis einfließen lässt.

Google is now using page loading speed in their ranking algorithm. The engineering of some sites can make this a difficult problem to fix quickly, so webmasters should study the problem now with speed detection tools such as YSlow and Google Page Speed.

Das wäre nur konsequent von Google, da bereits die Webmaster-Tools in der Google-Administration die Seitengeschwindigkeit ausweisen. Zudem profitiert Google von schnellen Webseiten indirekt, da der Aufwand für die Indizierung sinkt bzw. die Updatezyklen kürzer sein können. Damit steigt auch die Aktualität von Suchergebnissen und das verbessert die Wettbewerbssituation für Google.

Wir freuen uns natürlich auch darüber, weil damit nicht zuletzt auch die Bedeutung von Last- und Performancetests steigt.

Diese Optionen für das JDK6 sollte man kennen, wenn man dem Garbage Collector bei der Arbeit zusehen will. Speziell für das GC-Tuning sind diese Optionen unerlässlich:

-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintReferenceGC

Details zu den Optionen und zur Auswertung kann man unter GC Tuning oder in der Liste der JDK-Optionen finden.