The slides from our presentation at The Ajax Experience are now posted on SlideShare. Enjoy!

Tweet This Post 

Eric Beland will be speaking on AJAX Load Testing Considerations at The AJAX Experience September 15th at 1:20. We hope to see you there!

Tweet This Post 

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.

Tweet This Post 

Testomatix 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!

Tweet This Post 

So, the unexpected passing of Michael Jackson has been causing quite a stir. An unintended consequence of this unfortunate story is that the people hit the Internet to confirm the rumors. They hit it hard, causing downtime at numerous web sites. (Arguably, an even less expected side effect of his passing is that when MJ brought down twitter, Iranians were unable to tweet about their ongoing revolt. Oh, Internet, how fragile you are…)

Is MJ’s departure a unique, record setting event? I doubt it. It’s part of a trend, and I think it’s going to become the norm. We all know that Internet usage hasn’t plateaued yet. In fact, once it does, that will be pretty big news. In the meantime, it continues to grow thanks to increasing connectivity, abundance of netbooks and mobile devices, innovation on the web itself and, of course, a growing awareness of the web’s ever-increasing utility.

Think of the DESIGN GOAL for IPv6: let’s make everything uniquely addressable. EVERYTHING. What were those mad men thinking? What could we possibly want to address? They were preparing for a technology-drenched future. Let’s pave the way for innovation, let’s address devices that don’t even exist yet. That will lead to an incredible increase in connectivity and overall network utility! More, cheaper devices, with new, unforeseen functionality! Everyone benefits.

But that’s just concept. In the meantime, mashup-based cross-pollination of web content is rapidly growing, and the trend is all up from here. That’s not just “people on the web” anymore, that’s people USING the web. This affects everyone. Can the pipes handle it? What’s the horse power behind your web app? If you don’t know, find out, because today’s traffic nightmare is going to be tomorrow’s drop in the bucket.

Tweet This Post 

I previously worked at a company, let’s call it “Edutech” to protect the innocent, that had developed a variety of customer-facing web applications to open their financial information to colleges around the country. The data-center manager, a friend of mine, once told me that they had spent over a million dollars on hardware (machines, SAN, etc) scaling one of our web apps. This application only had to support around 250 concurrent users. I was shocked.  Edutech went years without load testing this particular application, even though it was under constant development.

The compounded effect of years of quick and dirty development decisions meant scaling the application in its current form wasn’t possible without the costliest cutting-edge hardware.  Previous development decisions had locked the app into approaches that worked effectively only at small scale.  Fortunately for Edutech, the function the app provided was so valuable that throwing money and hardware at it was a viable strategy. Load testing was being introduced, as a practice, for the first time at this company that year, because the costs of scaling the application had finally pushed the needle to a point where upper management took note.

Testing is a crucial step in the software development cycle, yet it’s often given short shrift.

Technical debt, a concept proposed by Ward Cunningham, suggests that, like financial debt, a price must be paid later when quick and dirty decisions are made in the development process.

The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object oriented or otherwise.

When load testing is a part of your release process, you escape the compounding interest of technical debt.  The moral is: test early, and test often.

Tweet This Post