I came across this interesting infographic comparing in-browser performance across Google, Chrome, and Internet Explorer. Poor, poor, Internet Explorer. Microsoft badly needs to get its mojo back.
![[Post to Twitter]](http://www.testomatix.com/blog/wp-content/plugins/tweet-this/icons/tt-twitter.png){kind=icon}
Google Announces Fast Sites Get Better Search Placement
April 9th, 2010Its official. Google just announced that faster websites now get a boost in search engine result placement.
See our previous discussion from when Google first floated the idea here. Also, do you need load testing?
Google may boost fast-loading sites in search result rankings
March 15th, 2010In this video interview, Matt Cutts, Google’s prominent, blogging, search engineer mentions Google’s is planning to give fast-loading sites a boost in Google’s search result positioning. This is a good move for Google in several ways. First off, Google’s users will be happier when they get the information they were seeking faster. Second, it provides a natural incentive for websites to speed up page load times, which will lead to a faster web all-around. Finally,it gives a boost to the real-time web for Google. Google can afford to spider fast websites more frequently, as they use less resources and require less time for the Googlebot to download.
The end result of all this is that it pays to ensure your site is fast–performance testing is more important than it’s ever been!
Browser Market Share Report
February 5th, 2010This new browser market share report is interesting. It is surprising to see Chrome at 5% already.
Load Testing Ajax Slides Are Posted
October 20th, 2009The slides from our presentation at The Ajax Experience are now posted on SlideShare. Enjoy!
Ajax Load Testing Gotchas – Part 1 (REST Verbs)
September 20th, 2009One current trend in web development is toward the proper use of REST (Representational State Transfer). Rest maps 4 of the HTTP verbs, GET, POST, PUT and DELETE to Create, Read, Update, and Delete actions within a web application.
Browsers do not have direct support for PUT and DELETE currently, although this is coming when HTML 5 eventually comes out. However, PUT and DELETE are already supported in the XMLHttpRequest implementation in all major browsers, so it is possible create proper REST implementations of Ajax forms. The gotcha in this case is that many load testing tools will have trouble recording PUT or DELETE requests, or problems running them at test-time. For the time being, if you are using Ajax forms, double-check to make sure your requests are properly recorded and replayed.
Testomatix will be presenting at “The AJAX Experience” conference in Boston
September 1st, 2009Eric Beland will be speaking on AJAX Load Testing Considerations at The AJAX Experience September 15th at 1:20. We hope to see you there!
Scaling Up vs Scaling Out at Stack Overflow
August 1st, 2009
StackOverflow, a popular programming website, has posted their architecture and scaling approach for their website. Their blog post has some excellent scaling tips, especially if you’re running a Windows/.Net stack.
The blog post also raises an interesting point regarding scaling up vs. out. Scaling up, a.k.a. vertical scalability, involves adding more memory and CPUs to a machine to gain performance improvements. Scaling out, or horizontal scalability, involves adding more machines to a system or part of the system in order to gain performance.
In recent years, scaling up has gotten bad press, as it has finite limitations that prevent it from being used effectively by the biggest sites on the web, like Google and Facebook. There is a limit to the ram and CPUs you can add to a machine. In the case of Stack Overflow, however, they have been mainly using a scale up strategy. The reality is most sites don’t have a need to scale to Google or Facebook-size proportions–so the choice is not a binary scale up vs out decision. Additionally, some tiers in a web architecture are easier to scale horizontally. For example, adding web servers is often a fairly straightforward proposition. However, adding database server machines is usually more challenging, as in some cases you will be looking at sharding, breaking off some piece of functionality like reporting, or moving to a master-slave setup.
If you run an open source stack, scaling out is more practical, in general. Stack Overflow was built on a Windows/.Net foundation where licensing costs provide a natural incentive to look at scaling up first, rather than scaling out. One take-away, to my mind, is that scaling up is a cost effective solution at certain stages in the growth of a web application. Scaling a website is normally a gradual process of continually removing the next most-pressing bottleneck. If you look at the growth patterns of larger websites, most started by plucking low-hanging fruit–often this involves scaling up a bit–like adding more ram, or CPUs to your database machine. Eventually, if your site attains a VERY large size, the optimizations you make are likely to make your application more complicated, and less flexible, so you pay a maintenance and design penalty for those optimizations. For example, database sharding, a scaling out strategy, tends to be done in the very late stages of growth, and the reason is that it limits how effectively some queries can run, and even whether some queries are possible. Scaling up, however, does not pose these problems.
Scaling up is a strategy worth keeping in your toolbox. Even if your plan is mainly scaling out, adding more ram and CPU to the boxes you are scaling can make sense. There is no shame in scaling “diagonally” when the situation warrants it. When choosing an architecture, know that architectures that only scale up will eventually hit a wall if enough growth occurs. That doesn’t mean your site will see enough traffic to hit that wall, and it doesn’t mean that scaling out can’t be done later. Realistic capacity planning is important at this stage. There is no need design every app to reach Google-scale. Sometimes vertical scaling is plenty, and when it is, it can be very cost effective.
As an aside, and on the flipside, with the advent of cloud computing and virtualization, there is a certain extra appeal to tearing the cost of scaling free from the moorings of software license costs. An OSS approach, which avoids licensing fees, can make it very cost-effective to run a full-size test environment in the cloud, on-demand, for testing purposes. This can provide tremendous advantages when testing performance and experimenting with different configurations.
FireFox 3.5 Bug on Windows and “works on my machine”
July 13th, 2009
Last week, a bug was discovered in FireFox 3.5 on Windows machines. To help generate a random number, FireFox reads the garbage data from the temp files and cache folders to “seed” the random number generator. Internally, random numbers are used within FireFox for security-related encryption functions. Unfortunately, on Windows machines with large Internet Explorer Caches, or Temp folders, reading the data used to seed the random number generator can take up to 40 seconds, and FireFox is barely usable.
This problem was presumably unanticipated because the development machines did not have large Internet Explorer cache folders, because FireFox developers mostly use…FireFox! It is an unfortunate reality of software development that code which worked well in a development environment may fail in the real world, especially if it hasn’t been tested and vetted against real-world data and usage patterns. The only way to escape the “works on my machine” problem is thorough testing with real-world data.
The same principle applies to testing the performance characteristics of web applications. The test data and scenario must be as realistic as possible to avoid this type of problem. For example, many SQL queries are blindingly fast with 2,000 records in a database, but when there are 2 million records, those same queries may return their results shortly after pigs fly. SQL queries (typically joins) that scale exponentially are a common scenario that can run into this type of problem. Although it can be difficult to get right, the more realistic your testing, the less margin of error for surprises after release, so test environments must be built with a careful eye on realism.
Testomatix is on Twitter
July 2nd, 2009Testomatix is now on Twitter. We’ll be posting our blog updates, as well as joining in discussions about load testing.
Twitter is an interesting place. Aside from being a walking case study on the need for load testing, it allows you to “have a conversation with the world” in a way that hasn’t existed in quite this way previously. We’re looking forward to participating in the world’s conversation about load and performance testing. See you there!