1

CSSE 477 – A bit more

on Performance

Steve Chenoweth

Friday, 9/9/11

Week 1, Day 2

Right – Googling for “Performance” gets you everything from Lady Gaga (http://justjared.buzznet.com/photo-gallery/2003211/lady-gaga-explosive-performance-03/ ) to a weird bicycle (http://www.rankfunny.com/Automobile/Exotic/Performance_Bicycle ) to a cloud database comparison (http://www.via.com.tw/en/products/processors/c7/ ).

2

Today

• Each team explain design changes and results (5 min. presentations with before / after demo.)

• More about performance, now that you’ve tried improving it!

3

Software performance - Strategic things to consider

• A mistake to wait and try to tune a big, new system at the end.– You can get by with this if you’re doing

incremental changes to an existing system.

• The big, new system needs software performance engineering.– Using a spreadsheet– Can move from there to queueing models or

discrete event simulation of key parts

4

Your assignment – not easy

• On the project you selected to work on, “Improve the performance by 100%.”

• But this happens in industry –– What if we grow to twice as many customers,

all using our servers?– Or, some part of the system has new,

competing uses – like other types of people using its data?

5

When do you need to know performance?

• For a new system:– Could be months ahead, as you are building it.– Customers need to budget for and order

servers.

• For an existing product offering:– You probably know more, from existing

customer experience.– But also need to predict system needs for

customers’ growth in usage.

6

What are the aspects of performance requirements?

• Capacity – how big a system has to be, or how fast– Like disk capacity or bandwidth

• Throughput – How many things per unit of time it can do– Like how many transactions per second

• Latency – How much delay can be tolerated– “Jitter” is a close relative of this

• Some of these terms differ in usage in the software industry!

7

Example of where to start

• Client is Time Warning, and wants a new system to handle pay per view subscriptions.

• These come in via set-top boxes, within their network.• They have 5 million customers in their biggest metropolitan service

area.• Maximum “take rate” for any PPV event is 3%.• Half of those who subscribe do so in the hour before the show

starts. For a single CPU to handle all this, what’s the maximum CPU time

that could be spent booking one customer?

This becomes a performance “target” based on requirements.

TIME WARNINGCABLE

8

Bass’s Performance Remedies

Review - From a week ago --

•Look at:– Resource demand– Resource management– Resource arbitration

•If you had a user interface based system, then speeding up the user activity was another alternative.

9

But, what do you worry about?

• Use 80 / 20 rule –– Look for the 20% of the functions of your

system that will use up 80% of the resources.– Don’t worry about the rest, unless you have

to.• This means, for instance, don’t waste your time

“shining” all the code for performance.• Decide first what code deserves taking extra time

to optimize it.

10

And how do you worry about it?

• Find peak periods – like we did in the example.

• Make assumptions, until proven wrong. Like:– Little’s Law – commonly used in statistics of

performance:

Occupancy of a resource = Arrival rate x Mean service time, or

Total seconds used = events / sec x # sec for each

11

What do “targets” turn into?

• You know Time Warning wants a system that will “handle” 20.83 transactions per second peak.

• You need to know what that “means” to your system –– Do you only book the customers for billing?– Do you actually have to enable their set-top boxes– Do you have to allocate the cable system’s

bandwidth, and stop when it runs out?

12

Make sure you know what the performance requirement “means”

• Some of these tasks would be much harder than others!

• Is the bottom line that Time Warning is out of bandwidth, and the probably really isn’t in the system that books customers at all?

• If they already have a system to do the required task, start by studying what it does.

13

Then start designing…

• Pick an architectural style that fits what the system has to do.– More on styles coming up next week!– Like client/server or pipe-and-filter

• Then “allocate budgets” across the components of the architecture:– Like on the spreadsheet from last Friday – “How much time can be spent in this box?”

• “How much of that in this software task?”

– The budgets help decide proper design!

14

Performance Engineering with a SpreadsheetTypical new system design analysis – For a network management system

Note: Having everything add up to only 60% allows for some “blocked time”

Note: Theseare all resourceconsumptionestimates

15

Budgets become vs Estimates which become Measurements

• As people do detailed design, they know if they can make those numbers or not.

• You keep looking at the budget, because that’s what tells you if the whole thing will run fast enough.

• As pieces of the system hit the lab, you can measure what really happens.

16

Typical remedies for bottlenecks

• Look for inefficiencies in the software– Like repeated database calls, waiting to

synchronize results, wrong priorities– Bugs like deadlocks and timeouts

• See link to case history, in notes for this slide

• Multi-thread the software• Get rid of competing tasks on the system• Add processors and distribute across• Add servers and distribute tasks

17

What do performance experts add?

• Most experts have some specific type of skill, like:– Software performance engineering– Queueing studies– Discrete event simulation studies

• You should already be close to knowing how the system will work, call them for a refined view or for confirmation. E.g.,– If the system already is too slow, then the effects of

queueing make it even worse!

18

Queueing example

• Single-server “M/M/1” model “queueing curve”:

ResponseTime

Utilization

19

Translating queueing-related requirements

• Requirement: “Response time less than 3 seconds, 95% of the time”.

• If you have an M/M/1 distribution of incoming work, what should the average response time therefore be?

Rp = R.50 x loge (1/(1-p))

• So, 3 = R.50 x loge (1/(1-.95)), and

R.50 = 3/2.995 = 1 sec, more or less.