If you read Percona’s whitepaper on Goal-Driven Performance Optimization, you will notice that we define performance using the combination of three separate terms. You really want to read the paper, but let me summarize it here:
- Response Time – This is the time required to complete a desired task.
- Throughput – Throughput is measured in tasks completed per unit of time.
- Capacity – The system’s capacity is the point where load cannot be increased without degrading response time below acceptable levels.
Setting and meeting your response time goal should always be your primary focus, but the closer throughput is to capacity the worse response time can be. It’s a trade-off! Cary Millsap reminds us to think of this just like how traffic slows down with more cars on a highway:
Photo Credit: photoAtlas
Which brings me to my point.
You can actually choose to optimize a system in two different ways – for response, or for throughput. When you optimize for throughput you are relaxing (not eliminating) your response time objectives in order to have more tasks completed per unit of time.
It is much easier to relax response time objectives if the task is not user facing, which is why I often see applications and suggest that they convert a task that happens in the foreground to instead be sent to a message queue, or Gearman. Or in plain English: The same MySQL servers can achieve much more work, if you allow the potential for each individual task to take a little bit longer.
Entry posted by Morgan Tocker | 2 comments
Add to: 
| 
| 
| 
| 
PlanetMySQL Voting: Vote UP / Vote DOWN