workload modeling for performance testing
- Thread starter murli
- Start date
The topics we intend to cover in this section are -
What is Workload Modelling
Need for Workload Modelling
Variation in Workload Modelling techniques
Why Workload Modelling is so important
Activities involved in Workload Modelling
Challenges involved in Workload Modelling
How-To’s on Workload Modelling
Deliverables on Workload Modelling
Resources on Workload Modelling
What is Workload Modelling – Let’s start out by defining Workload and then move onto the subtle differences in Workload modelling for different aspects of Performance Engineering across the Software Development Life Cycle. Workload can simply be defined as a logical set of activities that need to be performed by users (business or customers using the system) towards achieving a certain (bbusiness or customer) goal. As a Practical Performance Analyst I would tend to characterize Workload into two main areas, Business Workload and Infrastructure Workload.
Business Workload – Business Workload is the logical set of activities that need to be performed in order to meet the business objectives and goals. As a Practical Performance Analyst you are expected to have a solid understanding of the customer’s business, his business model, what makes the business tick, what are the different business initiatives that will impact performance of the platform including the different relevant aspects of Business Workload you need to consider on your program. Business Workload would imply different things for different businesses and different individuals within the same business. For example let’s take an online retail business. For the online retail business the business workload on its applications would include – Page Views/Hour, Orders Submitted/Hour, Mails Sent To Customers/Hour, etc. For a business with interests in the online retail banking space the workload would include – Page Views/Hour, Check Account Balance Transactions/ Hour, Withdraw Money Transactions/Hour, Messages to the Core Banking System/Hour, etc. Business Workload differs from one customer to the other and even across business units within the same customer based on the nature of the task being performed and the application that has been designed to address the task. Simply speaking Business Workload consists of a logical set of activities that need to be performed by the application in order for the business or customer to meet its stated objectives and goals.
Infrastructure Workload – Infrastructure Workload on the other hand is relatively easy to understand and appreciate. As a Practical Performance Engineer Infrastructure Workload consists of the logical units of work, that are performed by the underlying Infrastructure to process Business Workload. Infrastructure Workload very simply put includes the following – CPU Utilization/5mins, Memory Utilization/5mins, IO Operations/5mins, etc. Infrastructure Workload should complement Business Workload and in most cases would have a strong relationship with Business Workload drivers for a given application. Later in this foundation series we will be looking at modelling Business Workload & Infrastructure Workload to be able t forecast performance of the applications and identify infrastructure capacity impacts.
Need for different Workload Modelling techniques – Workload modelling techniques would differ slightly based on the activity you are engaged in across the Performance Engineering life cycle. As a Practical Performance Analyst I have found myself having a few different views on the Workload modelling techniques required depending on the nature of the program and the objectives of the Performance Engineering assignment I have been working on. Some of the Practical Performance Analysts out there might argue that all you need is probably just one version of the Workload model irrespective of the Performance Engineering activity (Performance Testing, Performance Modelling, Capacity Management, etc) you are involved with but then again every man unto himself (or woman unto herself…J).
Experience has told me that this isn’t the case and most of the times it just not practical to over simplify Workload models and collapse all detail into one single large common Workload model which not only doesn’t serve the purpose but also goes a long way to confuse the end consumer of the model i.e. the customer performance testing or capacity management teams.In instances where the workload is really simple you could indeed get away with just one version of the Workload model for different Performance Engineering activities but in instances where the applications are really large and complex you will need to invest in building separate custom workload models for the different Performance Engineering activities across the Software Development Life Cycle.
One of the reasons I also recommend you have different Workload models is to simplify the interpretation of those Workload models given the different teams you are engaged with across the customer site. Performance Testing teams don’t generally have any understanding of Capacity Management and less and understanding of Performance Modelling techniques. You’ll do yourself a big favor by being Practical and focusing on building custom Workload models based on the tasks at hand and the customer teams you will be involved with.
Variation in Workload modelling techniques – Workload modelling techniques as mentioned earlier could vary depending on the Performance Engineering activity and the objectives of the program you are involved with. The most complex Workload models in our experience are required for purposes of Performance Testing or SVT (Stress Volume Testing) while Capacity Management Workload models tend to be easier to design. Please don’t confuse Workload models with Capacity Models or actual Application Performance models which are two completely different things.
Let’s have a brief look at the different Workload models and what is their relevance from a Practical Performance Analyst’s standpoint. Workload models for Performance Testing ideally require you to gather the following Workload data from the perspective of documenting the various aspects of the Business Workload along with the accompanying Non Functional Requirements to be used as Performance Testing objectives on the engagement –
User Concurrency Targets
Transactional Workload (OLTP Workload)
Throughput Targets
Response Time Targets
Think Time Assumptions
Messaging Workload
Throughput Targets
Response Time Targets
Workflow Workload
Throughput Targets
Response Time Targets
Think Time Assumptions
Batch Workload
Duration Targets
Volume processed Targets
What is Workload Modelling
Need for Workload Modelling
Variation in Workload Modelling techniques
Why Workload Modelling is so important
Activities involved in Workload Modelling
Challenges involved in Workload Modelling
How-To’s on Workload Modelling
Deliverables on Workload Modelling
Resources on Workload Modelling
What is Workload Modelling – Let’s start out by defining Workload and then move onto the subtle differences in Workload modelling for different aspects of Performance Engineering across the Software Development Life Cycle. Workload can simply be defined as a logical set of activities that need to be performed by users (business or customers using the system) towards achieving a certain (bbusiness or customer) goal. As a Practical Performance Analyst I would tend to characterize Workload into two main areas, Business Workload and Infrastructure Workload.
Business Workload – Business Workload is the logical set of activities that need to be performed in order to meet the business objectives and goals. As a Practical Performance Analyst you are expected to have a solid understanding of the customer’s business, his business model, what makes the business tick, what are the different business initiatives that will impact performance of the platform including the different relevant aspects of Business Workload you need to consider on your program. Business Workload would imply different things for different businesses and different individuals within the same business. For example let’s take an online retail business. For the online retail business the business workload on its applications would include – Page Views/Hour, Orders Submitted/Hour, Mails Sent To Customers/Hour, etc. For a business with interests in the online retail banking space the workload would include – Page Views/Hour, Check Account Balance Transactions/ Hour, Withdraw Money Transactions/Hour, Messages to the Core Banking System/Hour, etc. Business Workload differs from one customer to the other and even across business units within the same customer based on the nature of the task being performed and the application that has been designed to address the task. Simply speaking Business Workload consists of a logical set of activities that need to be performed by the application in order for the business or customer to meet its stated objectives and goals.
Infrastructure Workload – Infrastructure Workload on the other hand is relatively easy to understand and appreciate. As a Practical Performance Engineer Infrastructure Workload consists of the logical units of work, that are performed by the underlying Infrastructure to process Business Workload. Infrastructure Workload very simply put includes the following – CPU Utilization/5mins, Memory Utilization/5mins, IO Operations/5mins, etc. Infrastructure Workload should complement Business Workload and in most cases would have a strong relationship with Business Workload drivers for a given application. Later in this foundation series we will be looking at modelling Business Workload & Infrastructure Workload to be able t forecast performance of the applications and identify infrastructure capacity impacts.
Need for different Workload Modelling techniques – Workload modelling techniques would differ slightly based on the activity you are engaged in across the Performance Engineering life cycle. As a Practical Performance Analyst I have found myself having a few different views on the Workload modelling techniques required depending on the nature of the program and the objectives of the Performance Engineering assignment I have been working on. Some of the Practical Performance Analysts out there might argue that all you need is probably just one version of the Workload model irrespective of the Performance Engineering activity (Performance Testing, Performance Modelling, Capacity Management, etc) you are involved with but then again every man unto himself (or woman unto herself…J).
Experience has told me that this isn’t the case and most of the times it just not practical to over simplify Workload models and collapse all detail into one single large common Workload model which not only doesn’t serve the purpose but also goes a long way to confuse the end consumer of the model i.e. the customer performance testing or capacity management teams.In instances where the workload is really simple you could indeed get away with just one version of the Workload model for different Performance Engineering activities but in instances where the applications are really large and complex you will need to invest in building separate custom workload models for the different Performance Engineering activities across the Software Development Life Cycle.
One of the reasons I also recommend you have different Workload models is to simplify the interpretation of those Workload models given the different teams you are engaged with across the customer site. Performance Testing teams don’t generally have any understanding of Capacity Management and less and understanding of Performance Modelling techniques. You’ll do yourself a big favor by being Practical and focusing on building custom Workload models based on the tasks at hand and the customer teams you will be involved with.
Variation in Workload modelling techniques – Workload modelling techniques as mentioned earlier could vary depending on the Performance Engineering activity and the objectives of the program you are involved with. The most complex Workload models in our experience are required for purposes of Performance Testing or SVT (Stress Volume Testing) while Capacity Management Workload models tend to be easier to design. Please don’t confuse Workload models with Capacity Models or actual Application Performance models which are two completely different things.
Let’s have a brief look at the different Workload models and what is their relevance from a Practical Performance Analyst’s standpoint. Workload models for Performance Testing ideally require you to gather the following Workload data from the perspective of documenting the various aspects of the Business Workload along with the accompanying Non Functional Requirements to be used as Performance Testing objectives on the engagement –
User Concurrency Targets
Transactional Workload (OLTP Workload)
Throughput Targets
Response Time Targets
Think Time Assumptions
Messaging Workload
Throughput Targets
Response Time Targets
Workflow Workload
Throughput Targets
Response Time Targets
Think Time Assumptions
Batch Workload
Duration Targets
Volume processed Targets
Good information krishna .. but looks like its copied from Rajesh's blog.
Please post a backlink in case you copy an article.
Please post a backlink in case you copy an article.
Thanks for sharing above verbose....
Can we have an example of how to create a workload model for an application which has already been deployed in PRODUCTION.
Let say if application server is JBOSS or WAS or any other...
what kind of logs do we need to analyse in order to understand the user & target volumes?
Which url's needs to be considered as in scope?
How to map url's to specific user journey?
Can we have an example of how to create a workload model for an application which has already been deployed in PRODUCTION.
Let say if application server is JBOSS or WAS or any other...
what kind of logs do we need to analyse in order to understand the user & target volumes?
Which url's needs to be considered as in scope?
How to map url's to specific user journey?
Hey Tanuj - Modelling usage of a live application is easy as we just need to capture current traffic and then extrapolate to growth numbers.
For any of the application you can follow below approach
- Use analytics tools for capturing current load
- Use web server access logs to capture the load statistics - More manual, parsing efforts will be required in this approach