Create An Application Map for Smarter Performance Testing

Create An Application Map for Smarter Performance Testing

Create An Application Map for Smarter Performance Testing


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”.


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.


There are logical resources which run on our computers. Below are some software categories and a few examples of each:

ComponentActual Implementations
Operating SystemLinux, Windows, MacOS, iOS, Android
Software LanguageJava, C#, Python, JavaScript, Elixir, SQL
Framework SoftwareBrowsers         ___ Chrome, Firefox, IE, Safari

HTTP Servers   ___ Apache, NGiNX, IIS

Application      ___ Java, .Net, Ruby on Rails, Angular JS

RDBMS            ___ SQL Server, Oracle, MySQL, PostgreSQL

ApplicationsSalesforce, 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


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.

Application Map Chart

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

  1. Know the “parts” of your application
  2. Create a “good enough” map of the application
  3. 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


Please follow and like us:

Follow by Email