Workload Modelling For Performance Engineering

Performance Engineering is a combination of Art and Science. Every activity across the Performance Engineering Life Cycle requires the Performance Engineer to have a good understanding of the relevant Application Workload. A sound understanding of the Application Workload is essential for any Performance Engineering task and without proper knowledge of your workload it would be impossible to define relevant Performance targets. Lack of relevant Performance targets would mean that the program won’t have any measurable outcomes from a Performance Engineering standpoint. You need to know where is it you would like to go before you start measuring how far you’ve traveled. This article will focus on the relevance of Workload modeling, it’s importance across the Performance Engineering Life Cycle (which mirrors the Software Development Life Cycle) and how would you as a Performance Engineer go about determining Workload for the relevant Performance Engineering tasks i.e. Performance Modeling, Performance Testing or Capacity Management. This article doesn’t focus on the technical aspects of Workload Modeling. Let’s focus on getting a good understanding of the process and once you’ve nailed that down we can focus on the technicality behind it.

What is Workload – Workload can be simply defined as the work done by the system to achieve a given outcome. Work done could be transactions processed, messages transferred, files copied, etc. Workload can be looked at from different perspectives i.e. Application Workload, Business Workload or Technical Workload. A Performance Engineer starts out by looking at workload initially from a Business standpoint, also called Business Workload models. A Business Workload model is created by the Performance Engineer working closely with the Business Analyst or Business SME to understand how the system will be utilized by business users or end customers.

Business Workload is then broken down into Technical Workload which is in essence the different technical transactions (or activities) that various components of the system perform to deliver the expected outcome measured from a business standpoint. Business Workload and Technical Workload in combination provide the Performance Engineer a good view of the overall Application Workload. In essence Workload models consist of high level Business Workload which is then broken down into Technical Workload for the relevant system components. Application workload models created by a Performance Engineer generally document all the main business critical (in terms of availability and performance as defined by business)  functionality that will be accessed by business users and end customers at any given point in time. Examples of Application workload are OLTP (Online Transaction Processing), Batch, Workflow, Messaging, etc.

Why do you need to document Workload – Workload models are built to give the Performance Engineer a view of the work being done by Business users which is then mapped to the technical transactions or work being done by the various different application components to achieve the objectives for the relevant business processes. Workload models are essentially a map of all the system activity across the various system components mapped to the actions performed by the business users and end customers. Documenting workload gives the Performance Engineer a good understanding of the activity across the various system components and confirms his or her understanding of the true nature of work being done by the system. Workload models are required input to all the different activities across the Performance Engineering Life Cycle i.e.

  • Non Functional Requirements Definition – Requires relevant Workload models
  • Performance Modeling – Requires relevant Workload models
  • Capacity Planning at Design – Requires relevant Workload models
  • Performance Testing – Requires relevant Workload models
  • Performance Monitoring – Requires relevant Workload models
  • Capacity Management – Requires relevant Workload models

Workload models are required input for the different Performance Engineering activities across the Performance Engineering Life Cycle. The nature of the workload in combination with the complexity will determine the approach taken to address the relevant Performance Engineering task. Application Workload models are in essence a map of  Business Workload to Technical Workload that are required to perform any Performance Engineering task across the Software Development Life Cycle. Get your Application Workload wrong and you’re in for a lot of trouble later on in the program since everything you do from a Performance Engineering standpoint relies on relevent workload models.

What activities requires Workload models – Every activity across the Performance Engineering Life Cycle requires Workload Models. A list of the various Performance Engineering activities across the Software Development Life Cycle are provided below:

  • Performance Engineering requirements gathering
  • Performance Modeling
  • Capacity Planning
  • Performance at Design
  • Performance Testing
  • Performance Monitoring
  • Capacity Management

A Performance Engineer needs to have a good understanding of the relevant Workload models based on what part of the Software Development Lifecycle they are in. While the overall Application Workload remains the same, the nature of Workload models will differ slightly from one Performance Engineering task to the other. The differences are mainly due to the need for certain types of data which form input to the different processes at the different stages across the Software Development Life Cycle.

How should i go about creating Workload models – The best way to go about creating Workload models is to start with the Business Analysts or Business SME on the program. As a Performance Engineer tasked with building an Application Workload model you have to start putting together the various building blocks from a Business Workload standpoint. A good picture of the relevant Business Workload components across the various application components is required before you move onto the Technical Workload models. The next step would be mapping the relevant Business Workload components to the various Technical Workload components across the system. As a Performance Engineer you would accomplish this task by sitting with the relevant Application Architect or Lead System Solution Architect on the program. There are numerous other ways you could go about creating your Application Workload models and it would differ based on the situation you are in. Treat these purely as guidelines for what you should be doing and tweak them based on the situation you find yourself in.

Challenges creating Workload models – I’ll take you through a few different scenarios here and discuss the possible options.

  • Lets assume that Business has little idea of what’s happening on the current system and are unable to provide input for the Business Workload models to be used for Performance Engineering of the new system. In such a situation your first port of call would be the Systems folk. Be-friend your Systems Administrator and get access to the relevant Web Logs, Application logs and Performance monitoring tools lying around the organization. This is the best way to extract data with regards to the most commonly executed business process. You’ll also need access to some statistical modeling tools and data visualization tools to model and visualize your workload.
  • Lets assume you’ve been able to work with the Business Analyst or Business SME on your program and define the relevant Business Workload models for the new system. However, since there is no existing system in place at the design stage you are unable to determine an exact mapping of the Business Workload to Technical transactions. This is a slightly better situation to be in as compared to the situation above. In such a situation you sit down with your Technical Architect or Solution Architect to create the relevant mapping of Business Workload model to Technical Transaction model. Make sure you document your assumptions around Technical Transaction volumes and complexity. Once you’ve nailed down the Application Workload model get both the Business SME and the Technical Solution Architect in a room and get them to agree on the Workload models that will be used on the program moving forward.

When do i know i am done – So the important point is when as a Performance Engineer do you know you are done with your Application Workload models. Generally speaking once you’ve obtained a complete listing of all the Business Critical Application workload and mapped them to the relevant Technical transactions across the various system components you’ve completed building your workload models. This by itself is no trivial task and you would have possibly had numerous conversations with Business SME’s and Solution Architects, sifted through volumes of production data or logs and run numerous statistical models to create your final workload models. Fortunately or unfortunately, nothing in Performance Engineering comes easy and you’ll have to work your way through the maze of data that surrounds you on any program to get your refined and useful numbers for your workload models.

You also know you’ve completed building your workload models when your Business SME’s and your Application Architect are in agreement with you on:

  • The mapping of Business Critical functionality to Technical workload
  • The forecasted volumetrics associated with each of the Business transactions
  • The forecasted volumetrics associated with each of the Technical transactions.

Getting everyone onto the same page – Workload models are an essential ingredient for any Performance Engineering task and the outcome of your Performance Engineering assignment (whether it is Performance Modeling, Capacity Planning, Performance Testing or Capacity Management) solely depends on the accuracy of your Application Workload models. You’ve definitely heard the saying, “Garbage In, Garbage Out” and sadly that’s the case on most of the programs i’ve reviewed over the years. Most Performance Engineers don’t plan to fail, they just fail to plan. People generally start out with poor (and in most cases none) Performance Engineering capability on programs, they then fail to ask the right questions, then incorrectly assume and document the wrong workload, agree with business on Non Functional requirements that aren’t realistic and cannot be met. Eventually when it’s time to validate application performance, everything goes pear shaped during Performance Test. It’s happened numerous times in the past and i am sure everyone of you has been a witness to at-least one such fiasco in your lifetime. Your ability as a Performance Engineer to ask the relevant questions to the relevant people at the relevant points in time will determine your success and the programs success as a whole from a Performance and Scalability standpoint.

Thus your ability to pull off this critical piece of work on getting both your Business SME and Application Architect on the same page is critical to having a set of Non Functional Requirements that the entire program can work towards achieving.

Workload Modeling is only the first step – Sadly but truly, Workload models are only your first step towards building applications that scale and meet their Non Functional Requirements. You have a long and winding road ahead of you as a Performance Engineer tasked with delivering a high performing application. A wise man once said, “When the going gets tough, the tough get going”. As a Performance Engineer you need to invest in building the right foundation on a program, working together with your Business SME and Application Architects to deliver reliable Application Workload models is only the first step in building applications that scale. Your next step is working on the relevant Non Functional Requirements and mapping them to the workload models for the different system components. Get your workload models right and you are on the right track to defining relevant Non Functional Requirements. A good start to a journey is a journey half complete. Best wishes and hope this article has helped your formulate a better understanding of Application Workload and the importance of Workload Modeling on any program.

As always do write to us with your input, comments and suggestions at trevor at practical performance analyst dot com. If you think you’ve got the the talent, are keen on sharing your knowledge and experiences as a Performance Engineer and want to help build the community, please drop us an email and we’ll find some good challenging work to keep you ticking.

Related Posts

  • Getting The Timing RightGetting The Timing Right I’ve argued for a long time now that getting the right Performance Engineering resources early on in the program can make a big difference, especially on large programs where complex applications, heavy workload and large volumes of data are concerned. This article looks at the merits of […]
  • Application Of Performance Modeling Techniques Application Of Performance Modeling Techniques What is Performance Modeling – Performance Modeling is the process of modeling application performance considering various growth factors with the objective of proactively predicting potential breach of SLA’s. Performance Modeling is also used to validate design decisions and […]
  • HowTo Create A Performance BudgetHowTo Create A Performance Budget Launching HowTo's - We have just launched a new section here at Practical Performance Analyst called HowTo's. Howto's much like their counterparts (in the Open Source movement) will focus on the specifics around different SPE (Systems Performance Engineering) related tasks. There is a […]
  • Non-functional Requirements in Architectural Decision MakingNon-functional Requirements in Architectural Decision Making This article first appeared in IEEE Software magazine and was then published by InfoQ at their website. In software engineering, a tight relationship exists between nonfunctional requirements (NFRs) and software architectures (SAs). As early as 1994, Rick Kazman and Len Bass asserted […]