1 / 32

Computer Systems Performance Evaluation

Computer Systems Performance Evaluation . CSCI 8710 Kraemer Fall 2008. Course Content.

Télécharger la présentation

Computer Systems Performance Evaluation

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. Computer Systems Performance Evaluation CSCI 8710 Kraemer Fall 2008

  2. Course Content • This four-hour course address computer systems performance analysis. It introduces the main concepts and techniques needed to plan the capacity of computer systems, predict their future performance under different configurations, and design new applications that meet performance requirements. The course is mainly based on the use of analytic queuing network models of computer systems. These techniques are applied to study the performance of centralized, distributed, parallel, client/server systems, Web server and e-commerce site performance. The course provides the students with hands-on experience in performance evaluation through a project. The concept and applications of software performance engineering are also covered.

  3. Course Web Site • http://www.cs.uga.edu/~eileen/8710/

  4. Grading Scheme • Your grade in this course will be calculated as the average of the following: • Homeworks -- 10% (A selected subset of the homeworks will be graded. ) • Quizzes -- 5% (One per paper presented.) • Paper presentation -- 10% • Midterm Exam -- 25% • Final Exam -- 30% • Course project -- 20% • Letter Grades assigned as follows: • 90 <= Grade A • 80 <= Grade < 90 B • 70 <= Grade < 80 C • 65 <= Grade < 90 D • Grade < 65 F

  5. Late Policy • Paper presentations must be ready on the scheduled date. Late submissions of projects and homeworks will be accepted with a penalty computed as follows: score = Max_Score * Percentage_Score * (0.90)^(days_late). • A day is a 24 hour period, rounded up to the nearest day. • For example: • You turn your project in 3 days late, and received a 95% score based on the work done. Your recorded score will be: • score = 100 * (0.95) * (0.90)^3 • score = 100 * (0.95) * (0.729) • score = 69 • Exception • In the case that a solution is distributed, no project submissions will will be accepted after distribution of the solution

  6. Collaboration Policy • The purpose of the homeworks is to familiarize the student with concepts and details of performance measurement techniques. These are individual HWs. • However, when students are “stuck” they may ask questions of one another, and respond to other student's questions, to the point that they help student overcome the obstacle but not to the point that they “give away the answer”. • Direct exchange of code or spreadsheets is prohibited, as is line-by-line assistance. • Exams are closed-book. No outside assistance is permitted. No additional materials may be used.

  7. Textbook • Performance by Design: Computer Capacity Planning by Example, • by Daniel A. Menasce, Virgilio A.F. Almeida, and Lawrence W. Dowdy

  8. Week 1 • Computer System Lifecycle

  9. The Importance of Performance inComputer Systems • Mission-critical applications • Life support applications • Homeland security • Battlefield situations • Personal communication systems

  10. QoS Metrics • Response time • Throughput • Availability • Reliability • Security • Scalability • Extensibility

  11. Response Time Breakdown • Service time (does not depend on the load) • • Congestion (load-dependent)

  12. Throughput • Measured in units of work completed over time. It’s a rate. • I/O’s/sec • Page downloads/sec • HTTP requests/sec • Jobs/sec • Transactions per second (tps)

  13. Throughput Example • An I/O operation at a disk of an OLTP system takes 10 msec on average. • What is the maximum throughput of the disk? • What is the throughput of the disk if it receives I/O requests at a rate of 80 requests/sec?

  14. Throughput example

  15. Availability • Fraction of time a system is available (i.e.,operational). • Service interruptions can damage the reputation of a company, may endanger lives, and may cause financial disasters. • A system with 99.99% availability over 30 days is unavailable (1-0.9999) x 30 x 24 x 60 = 4.32 minutes.

  16. Availability Problems

  17. Admission Control

  18. Admission Control •Improved response time •Decreased availability

  19. Scalability System A is not scalable

  20. Extensibility • Property of a system to constantly evolve to meet functional and performance requirements. • Autonomic computing, self-managing systems, self-healing systems.

  21. Computer System Lifecycle • Functional requirements: what the system has to do and on what type of platforms. • Non-functional requirements: how well the system has to accomplish • its functions. Service Level Agreements (SLA) are established. • In many cases, non-functional requirements have been neglected or • considered only at system test time!

  22. Computer System Lifecycle • How will the requirements be met? • - System architecture • - System broken down into components • - Major data structures, files, and databases are designed. • - Interfaces between components are specified

  23. Computer System Lifecycle • Components are implemented. • - some are new • - some are re-used • - some are adapted • Components are interconnected to form a system • Components should be instrumented as they are built

  24. Computer System Lifecycle • Concurrent with system development, as components become available • (unit testing) • Integrated tests are carried out when the entire system is ready. • Often, more time is spent in testing functional requirements than in testing non-functional requirements.

  25. Computer System Lifecycle • Configuration parameters have to be set in order to meet the SLAs. • e.g., TCP parameters, database poolsize, maximum number of threads, etc.

  26. Computer System Lifecycle • Constant monitoring to check if the system is meeting demands: • workload (peak periods, unusual patterns) • external metrics (user-perceived) • internal metrics (help to detect bottlenecks and to fine tune the system) • availability (external and internal) • May need to dynamically adjust configuration parameters

  27. Computer System Lifecycle • Systems may need to evolve to cope with new laws and Regulations (e.g., HIPPA) • Systems may need to evolve to provide new functions (e.g., sale of downloadable MP3 music in addition to CDs) • How are the IT resources going to cope with evolution in terms of SLAs?

  28. Reference Model for IT • Business Model: • - number of branches • - number and location of ATMs • - number of accounts of each type • business evolution plans (e.g., mergers) • Social Model • - privacy policy • - accessibility policy

  29. User Model: Customer Behavior Model Graph

  30. IT Infrastructure: Example

  31. Homework #1 • Page 30, #1 and #2 – try them, if you can • Page 30, #3 and #4 – write them up

  32. Tomorrow • Paper presentation session 1 • scheduling, selection of papers, discussion of best practices

More Related