Climbing the peak

Scenario In your usual sizing efforts you need to know the peak usage% for a certain workload and server(s). What is the right averaging time to capture this peak? Let’s see possible choices. Too long averaging time Averaging Time = 500 min. Peak usage% = 50%. Total loss of finer details. Does this really mean […]

Continue reading

The degraded operations pitfall

Let’s consider an information system supporting a highly critical online activity. Critical means it cannot fail, and if it fails there must be a contingency infrastructure that allows operations to continue “reasonably” well, with zero or tolerable performance impact. Someone trying to reduce acquisition cost decides having half of the processing capacity in the contingency […]

Continue reading

The upgrade sizing pitfall

The art of sizing is not exempt of pitfalls, and you must be aware of them if you want your sizing to be accurate and adequate. Let us talk about a typical scenario: a server upgrade. All the metrics in sizing are measures of throughput, and this has an implication you must take into account: […]

Continue reading

What does Usage mean?

My objective today is to clarify the meaning of one of the most used metric in sizing and in performance analysis: the usage. First things first The Usage exposes the state of the service center. It is a binary quantity: usage=0 when idle (not working) usage=1 when busy (working) Any service center at any point […]

Continue reading

Phases of the response time with variability

Let’s go to the response time versus the number of users signature (graph below) in the simple system described in “Phases of the Response Time”. We made two simplifying assumptions: the service time is constant, and the interarrival time is constant (the the think time is constant). These assumptions allowed us to distill the essence […]

Continue reading

Data tiering: a simple performance analysis

A certain transaction uses 1 ms of cpu time and 20 ms of IO time. With a think time of 10 s the system supports 550 users with a response time R below 1 s. Now the same system is equipped with a faster storage where part of the data is placed. When this data […]

Continue reading

The scalability of the software

The developers team in the ABC company has just built a five star transaction / program. The program code has a critical region. Basic performance tests with a few users result in a the total execution time of 1 s, with a residence time in the critical region of 0.05 s. These numbers are considered […]

Continue reading

Phases of the SAPS Benchmark

The SAPS benchmark fits very closely in the model analyzed in the post “Phases of the Response Time”. In essence the benchmark is performed by progressively increasing the customer population, and monitoring the response time.  When response time reaches 1 second, the measured throughput, as expressed in dialog steps per minute, is the SAPS value. […]

Continue reading

Phases of the Response Time

Let us consider a fixed (closed) population of users interacting with a service center, as shown in the following picture below: At t=0, an user arrives to the service center, From t=0 to t=W the user waits in the queue if all the servers (or workers) are busy at t=0,  W is the wait time. […]

Continue reading