03 Mar Create An Application Map for Smarter Performance Testing
PART 1: (PART 2 IS SHOWN BELOW)
Maps Are Invaluable
Have you ever tried to drive in an unfamiliar city without a map? It’s next to impossible. Sometimes it feels like you’re never going to get to your destination. Never mind that you don’t know the traffic patterns. You could get stuck for hours.
It’s the same experience if we attempt to performance test an application without a “map” of the system. We have no idea which direction to take, or if we’re taking the only bridge available, or if our destination requires a trip out of town.
Some people say, “But most applications don’t come with a map.” I know. I feel your pain. However, with a few questions with the right people, you’ll have a map that will help you get where you want to go.
Your Application “City”
Before we create our map, we need to first think about the parts of our application “city”.
Computers
In an unfamiliar city, we know the kinds of features we’ll come across: roads, buildings, bridges, highways, and more. In applications, there is one feature that is everywhere, computers. And every computer has the following four components:
- CPU
- Memory
- Disk
- Network
Just about everything relies on these four resources. Your phone, your laptop, network routers, switches, cell towers, and every server on the planet. We need to be alert to the fact that these fundamental resources, whether physical or virtual, may prove to be a bottleneck.
Software
There are logical resources which run on our computers. Below are some software categories and a few examples of each:
Component | Actual Implementations |
Operating System | Linux, Windows, MacOS, iOS, Android |
Software Language | Java, C#, Python, JavaScript, Elixir, SQL |
Framework Software | Browsers ___ Chrome, Firefox, IE, Safari HTTP Servers ___ Apache, NGiNX, IIS Application ___ Java, .Net, Ruby on Rails, Angular JS RDBMS ___ SQL Server, Oracle, MySQL, PostgreSQL |
Applications | Salesforce, Slack, Dropbox, etc. etc. etc. |
Hidden inside each of these pieces of software are bottlenecks: be it queues, connection pools, errors, exceptions, configuration settings, and on and on and on. Make no mistake, there are bottlenecks everywhere. They may not matter, because we may never reach the magnitude of traffic where they would be felt. But they are there.
What’s Next
In this first blog post, we’ve discussed the “landmarks” in every application’s “city map”. In the next post we’ll discuss a general map, and then how to modify it to match your application.
Tom Horsfield
PART 2
In part 1 of this blog series, we discussed the landmarks which we find in every application. You can find that post here. (Add a URL behind the word “here”).
A Generic Map
Knowing that computers and software are the main features of our application “city”, below is a generic “map” for a web application.
Now it’s Your “Turn”
We can take this general map, ask some questions about the technologies in our actual application, and make the map useful for “traveling” around our system to see how it performs. Two notable ideas to make our maps more valuable:
Idea #1 ~ “Good Enough is Good Enough”
Ask just enough questions so that your map is “good enough”. Document the big facts (e.g. JavaScript rich pages? REST API?) and essential details (e.g. SQL Server?) and get testing as soon as you can. Fill in more detail as you go.
Idea #2 ~ “Paralysis of Analysis” or Don’t Just Sit There Looking Around
You don’t want to waste tons of time acquiring every little detail about the system, and then never actually “drive through the city”. Okay, you caught me, this idea is just a repackage of #1. But it can’t be emphasized enough.
A Recent Win
During the discovery phase of a load testing engagement, we were having issues getting scripts to run against the primary Windows desktop application. Then, in a conversation with a developer, we discovered that the application also had a SOAP Web Service available. Eureka! We switched gears to running load via the Web Service and saw a much more promising future.
In Summary
- Know the “parts” of your application
- Create a “good enough” map of the application
- Start “driving” around your app’s map, taking different routes, always on the lookout for relevant bottlenecks
Do you have a story of an approach like this? Shoot me a note or ask any questions you may have.
Thanks and good travels,
Tom Horsfield