Performance Requirements?

Design for performance: Requirements

Before designing an architecture, we should know what we want. Our goal here is to include performance as part of the solution, not part of the problem.

The real problem for me in completing this document with my customer, is the customer didn’t think of response times while trying to solve his problems. That’s why I suggest always giving the user a couple of choices. Ask them what feels right, what feels acceptable? Not, want they want, because most of the time, they don’t know or it isn’t realistic. I will discuss this subject (Performance Psychology) later on, in on of my next blogs.

General

• Response time(ms): It’s common to here to make a difference between writes and reads operations(get/post).
• Average(ms): What do you expect?
• Maximum response time(ms): What is acceptable?

Note: I normally split this up in, maximum time under normal circumstances and while the system is under heavy load.

• Throughput(hourly of minutes): maximum amount of requests your system should be able to handle. Think of spikes.
• Concurrent Users: How many users will be using the system at the same time.

User type

Depending on the type of user using the system, these will vary enormously.
Interactive(Human)? Is a person using the system?
Synchronous  or As-synchronous: The “micro”second the user can continue working, is the time you should measure.
Batch/Scheduled(Machine)? Is an application using your application? Define your time window and don’t forget, you are not alone! Other batch jobs of application can be running at the same time.

Scope

Define these previous requirements for the entire application and for specific business cases.

Application requirements

The application requirements are good defaults. These requirements will also help you decide what kind of hardware you will need.

Business requirements

Performing Business logic is key, so performance should play a part in here as well.

Eligible Business cases:

• Frequently used scenarios
• Performance-intensive scenarios
• Business-critical scenarios
• Scenarios of special interest

For business cases add the following requirement:

Task driven (Usability/Performance)

Task completion: How much time would the person need to accomplish the task?
Task feedback loop: How fast can we give the user feedback about his task?
This may not sound like a performance criteria, but here you can gain the most time. By smart interface design, you can solve problems faster(performance) and better.

Technical

Resource cost: CPU, file access, network, data access....
You will have limitations, either from your own system(hardware), or an other systems you are working with.
Volatile data: Decide how volatile the data(ready to change) is. 

• Very Volatile(data changes often): Make the data you need as small as possible. 
• Not Volatile(data doesn't change often): Caching maybe? It’s not a must, but think about it.

Most data lays somewhere in between, so always be careful, how much data you need(less is more).

Scalable: This is closely related to the resource cost. You should watch out for bottlenecks here. Ask yourself the question: In case my application grows, where will it have the most impact? Can we handle this additional load, or can we scale it(example: more hardware)? This question will be handled in my next blog post. (Scalable Architecture)

Would you like to know more:


http://www.testingreflections.com/node/view/4432

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/doc_perf_reqs.htm
http://www.perftestplus.com/resources/requirements_with_compuware.pdf


Remember: Performance is a part of solving the problem, it doesn’t stand alone!

These are my two cents. In case you have something to add, or even better, something to take away(perfect design). Do tell!