1 / 19

CSSE 477 – A bit more on Performance

Learn about strategic approaches to improving software performance and the importance of performance engineering. Discover how to set performance targets and allocate budgets for different components of the system.

sherrod
Download Presentation

CSSE 477 – A bit more on Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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/ ). CSSE 477 – A bit more on Performance Steve Chenoweth Friday, 9/9/11 Week 1, Day 2

  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 TIME WARNING CABLE • 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.

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

  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?Rp = R.50 x loge (1/(1-p)) • So, 3 = R.50 x loge (1/(1-.95)), andR.50 = 3/2.995 = 1 sec, more or less.

More Related