A developer's guide to load testing
London User Group - Tuesday 9th June 2009, 18:30-20:00
Here are the details of the June 2009 London User Group.
- Title : A developer's guide to load testing
- Summary : Load testing is an often forgotten and seemingly difficult task that many people shy away from doing. It doesn't have to be this way though, with a basic level of load testing often enough to give you confidence that you've satisfied your non-functional requirements around performance and scalability. This session will look at load testing a website from a developers perspective. We'll look at the differences between load testing, stress testing and soak testing along with a hands-on demonstration of an open source load testing tool that you can use to get started. If you're building websites in Java, .NET, PHP or indeed any other programming language, this session will show you how easy it is to load test your website.
- Date : Tuesday, 9th June 2009
- Time : 18:30-20:00
- Location : Skills Matter, 1 Sekforde Street
- Format : Presentation and discussion, with further discussion in a local pub (The Crown).
- Cost : Free, but registration is required.
Many thanks to Skills Matter for sponsoring the user group.
p.s. this session is being run after the second day of our software architecture training at Skills Matter in London ... there are a couple of places left if you want to come along and learn about software architecture.
Interview from DevWeek 2009
Transitioning into a software architecture role
Eric Nelson from Microsoft interviewed me at the DevWeek 2009 conference about our software architecture workshop, transitioning into an architecture role and whether architects should code. Take a look ... it's a nice overview of our approach to software architecture and to training software developers to be more architecturally aware.
There are some other interesting interviews from DevWeek 2009 on the YouTube channel too. Thanks Eric!
Using new technology will make it faster
Not necessarily!
I heard an interesting throwaway comment recently that I thought I'd share. To paraphrase...
The system is being rewritten with new technology, so it won't be slower than what we have now.
While it's true that new and updated technology *can* improve performance, it's also very easy to misuse that technology and come up with something that performs perceivably slower. I've seen this a few times, predominantly where simple websites have been rewritten using new technologies. One of the biggest contributing factors is that new technologies often provider "better" and more complex ways to solve the same problem. For example, it's easy to see how a simple two-tier web application could be rewritten with a web-MVC framework and a distributed middle-tier added to make the architecture more fashionably SOA-like. Here, the added complexity could result in net performance gains or losses, depending on how the technology is applied through the design and architecture.
There's nothing wrong with refreshing a software (or hardware) system with new technology, but it's naive to assume that performance won't degrade. New technology generally brings added complexity, and this complexity introduces more things that can go wrong. Any software/hardware architecture should undergo *some* non-functional testing before it goes live, and this still holds true for systems that are being rewritten as part of a technology refresh strategy. Don't assume anything ... test it.
Software architecture training in London
8th and 9th of June 2009
The next public run of our software architecture training is taking place on the 8th and 9th of June, at Skills Matter in London. This is a two-day course that Kevin and I put together to explain what software architecture is and what the role is all about. It's aimed at anybody with software development experience who would like to become more architecturally aware and draw some pictures on whiteboards in the process!
The course is about broadening your software development skills while being designed to take full advantage of the technical knowledge that you already have, whether your background is with Java, .NET or anything else. In the current financial climate, now is exactly the time to broaden your skills and become more architecturally aware.
See the Skills Matter website for other dates and costs. Book before the 9th of May to receive the early booking discount.
Adding the fuel gauge
Getting feedback from our software
One of my talks at the recent DevWeek conference was about the pitfalls software architects face and I covered some of the problems associated with technology selection. Probably *the* biggest problem is vendor marketing and hype, with many project teams simply taking this at face value. Sometimes a piece of technology will do exactly what it says on the tin, but sometimes it won't. There are truly no silver bullets and every technology, large or small, has trade-offs. You've probably seen this yourself at some point. Vendors (open source and commercial) promising features that they haven't yet implemented through to bold claims about performance or scalability. Depending on your project context, these promises can often make or break your project.
One of the analogies that I made during the session was about the fuel consumption figures quoted by car manufacturers in their glossy brochures. Let's imagine that you need to travel from one side of the country to the other, work out the mileage and then buy or rent a car based upon the fuel consumption figures quoted in a brochure. The quoted consumption figures are usually based on some optimum conditions but real world figures will vary according to the way that you drive, the speed you drive, the ambient temperature, the gradient, the road surface and so on. Depending on all of this, you may or may not achieve your goal.
When we undertake a technology selection exercise, we'll typically evaluate candidates against a set of criteria and choose the one that we think best suits our needs before plugging it in to our projects. Not testing the technology before adoption is the same as driving a car across the country - you're relying on somebody else's claims and it might not go as expected. Literally, your mileage may vary!
Of course, the key difference is that you get a fuel gauge in a car that provides you with constant feedback of how much fuel remains in the tank. In addition, newer cars have onboard computers that can provide you with real-time consumption figures and estimate the mileage remaining. This is all information and it provides a way to monitor what is happening so that you can adjust (or fill up!) as necessary. Laptop batteries are the same. The manufacturers quote maximum battery life figures and while you might not get that in real world usage, you do get to see how much battery life is remaining.
With this in mind, it's worth thinking about why we don't usually add fuel gauges to our own software systems. These systems are usually composed of many complex technologies, each of which makes its own claims and has its own trade-offs. Yet we often deploy and run our systems as a black box. Often this will work but sometimes it won't. And worse still, without a fuel gauge you have no idea when your system will grind to a crawl or stop working completely.
Adding a monitoring capability is fairly easy to do and can give you important insight into the health of your software. For example, it might allow you to monitor how many database connections are being used, or how many messages are waiting to be processed, or how many worker threads are busy servicing user requests. Here are some thoughts on how to cater for monitoring in your architecture, and they're particularly relevant if you're building Java applications.
As with cars and laptops, there are benefits to be had by adding some simple feedback devices to our software systems. After all, wouldn't it be great if you could understand the health of your system and proactively deal with problems before they become major issues?
