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 ( gallery/ /lady-gaga-explosive- performance-03/ ) to a weird bicycle ( Exotic/Performance_Bicycle ) to a cloud database comparison ( cessors/c7/ ). gallery/ /lady-gaga-explosive- performance-03/ Exotic/Performance_Bicyclehttp:// cessors/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 WARNING CABLE

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” 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 Spreadsheet Typical new system design analysis – For a network management system Note: Having everything add up to only 60% allows for some “blocked time” Note: These are all resource consumption estimates

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”: Response Time 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? R p = R.50 x log e (1/(1-p)) So, 3 = R.50 x log e (1/(1-.95)), and R.50 = 3/2.995 = 1 sec, more or less.