This is Part II of a V part series. You can read the first post here – SPE 101 – Refreshing The Basics – Part I
Introduction – It’s been a while since we have touched upon the basics of SPE (Systems Performance Engineering) here at Practical Performance Analyst. The SPE Fundamentals section here at Practical Performance Analyst covers the basics of SPE (Systems Performance Engineering) cover details with regards to the definition of quantities, definitions of various processes, deliverable that could support potential outcomes including the tools required to automate the various processes across the delivery and support lifecycle.
With regards to the SPE (Systems Performance Engineering) basics, everyone can do with a refresher once in a while it so why not take a quick peek at some of the basic definitions of SPE (Systems Performance Engineering) quantities that most of us deal with in our day jobs across technology. In the first part of this series we took a detailed look at a couple of very common but important quantities namely i.e. Response Time and TTFB (Time To First Buffer). To read more on the SPE (Systems Performance Engineering) basics please visit the SPE Fundamentals section at SPE Fundamentals. In this section we will go over some important and frequently used SPE related terminology.
As I walk you through each of these basic quantities I will help you understand their relevance from a Systems Performance Engineering standpoint. Obtaining a good understanding of these definitions will also help you ask the right questions when working on a performance or capacity related challenge. In this episode, let’s start by taking a look at one of the most commonly used terms, “Think Time”.
Think Time (Zt) – Applications are generally built to automate business processes and each business process could be viewed as a collection of numerous simple user actions that are strewn together to achieve a certain objective. Unlike robots users rarely perform such actions repeatedly or in succession one after the other without pausing for thought or performing some action required to provide the application input. Users generally tend to perform actions in repeated sequence with varying amounts of time between them depending on the complexity of the relevant user action i.e. the action of filling up a simple form could vary from 10-30s before the user hits the submit button.
Think Time is thus defined as the time taken by a user between two consecutive actions and is generally represented by the letter Z (According to Little’s Law i.e. N = (R + Z) * X where R – Response Time, Z – Think Time, N – Number of Users in the System and X – Throughput). Think Time is usually measured in terms of seconds and is represented as follows : Z = 30s
Think Time plays a very important role in Systems Performance Engineering including on-going Performance & Capacity Management of any system. Without a good understanding of your user’s Think Time you can end up building unrealistic Performance Models required to simulate system performance or even end up building Workload Models for Performance Test which could impose higher than expected workload on your systems. It’s important to understand the concept of Think Time and more importantly how the concept of Think Time applies to your system in general.
Let’s see how accuracy of Think Time can affect the outcome of a simple performance test:
- Real value of Z = 30 seconds
- Incorrectly Assumed value of Z = 5 seconds – In this case the Performance Testing Workload Models you build will end up performing actions and eventually business transactions at a higher rate than what the system in production would actually be handling. As a result the system in Performance Test is going to be forced to handle a lot more workload that it actually would in a normal production scenario.
- Incorrectly Assumed value of Z = 60 seconds – In this case the Performance Testing Workload Models you build would end up performing actions and eventually business transactions at a much lower rate than what the system in production would be eventually handling. As a result the system in Performance Test isn’t going to be stressed hard enough and you wouldn’t have a true understanding of what the real end user performance is going to look like.
In general during Performance Test one sets up the run settings such that Think Time (Z) is varied between a set of given constants. This is to introduce variability mimicking the nature of different clients accessing the applications. Thus an accurate understanding of Think Time for each of the critical business processes is essential for you as the Performance Engineer to accurately simulate Workload Models during Performance Test, Modelling application performance during Architecture/Design or Predicting Capacity impacts at go live.
Now that we’ve looked at the definition of Think Time, let’s look at the definition of “Service Time” and how it might apply to the work you do from a Performance Engineering standpoint.
Service Time (St) – Service Time or St is simply defined as the time taken by the system to process a particulate service request. Service Time tends to remains constant for a given transaction when there is no change in any of the user inputs or other environment variables that govern the performance of the given business transaction.
- Rt = Wt + St ……………………. [ Wt = Wait Time, St = Service Time ] also written as
- Rt = Qt + St ……………………. [ Wt = Wait Time, Qt = Queuing Time ]
Service Time is the constant in the above equation for a given set of input parameters. What generally causes the Response Time to vary is the Queuing Time [Qt] or Wait time [Wt] variable which depends on various factors including congestion at a given resource, sudden increase in demand for a given resource, etc. Service Time like overall response time can be measured at the Network tier, Hardware tier, Disk tier, CPU tier, etc. is a known constant.
Thus next time around when someone suggests degradation in Service Time for a given business transaction what they are actually implying is that the Response Time for the given business transaction has degraded due to increase in the Waiting Time for computational resources required to process the given transaction. Service Time in this case will remain a constant as long as there is no change in any of the input variables or volume of data provided as input.
Service Time Equation – Service Time for a given resource can also be modeled using some very basic Performance equations. Let’s look at the following scenario.
- We start watching a system at t=0 and end viewing of the system at time t=T
- The duration for which the system has been busy is described by Bt
- During the time T there were C Completions (successfully processed transactions)
- The Service Time for a particular transaction can thus be defined as:
S = Bt / C …………………. [ Bt = Busy Time, C = Completions ]
Example – Let’s say we’ve observed a system for 60 seconds and within the 60 seconds the system has had 15 Completions or 15 successfully exited customers. The Service Time each customer can be calculated as: Service Time = 60 / 15 = 4s
We’ve chosen to apply the above scenario to an overall system but this could also be applied to a component within an existing system. The Service Time equation is one of the most basic equations used to identify the service time for a given resource within a system or even the system as whole.
Conclusion – Think Time and Service Time are some of the fundamental quantities that make up most of the basic equations that Performance Engineers use very frequently to understand and model their system Performance. Use of these quantities and equations in general is not limited to IT systems but also any system that you come across in real life i.e. banks with tellers where you stand for service, coffee shops where you queue up to be served, etc. We would highly encourage you to build on these concepts by visiting the Systems Performance Engineering (SPE) Fundamentals section at Practical Performance Analyst SPE Fundamentals.
Trevor Warren (Linked In) loves hacking open source, designing innovative solutions and building communities. Trevor is inquisitive by nature, loves asking questions and some times does get into trouble for doing so. He’s passionate about certain things in life and building solutions that have the ability to impact people’s lives in a positive manner is one of them. He believes that he can change the world and is doing the little he can to change it in his own little ways. When not hacking open source, building new products, writing content for Practical Performance Analyst, dreaming up new concepts or building castles in the air, you can catch-him bird spotting (watching planes fly above his house).
Practical Performance Analyst as an Open Body Of Knowledge on Systems Performance Engineering (SPE) built + maintained by Trevor with the support of his army of volunteer elves (PPA Volunteers). You can reach trevor at – trevor at practical performance analyst dot com. The views expressed on this web site are his own.