CS457 - System Performance Evaluation - Winter 2010

Public Service Announcement

  1. Assignment Mark Weighting : 15%, 25%, 20%, 40%
  2. Assignment 2 preview

Lecture 9 - Measuring Performance

Consider the following scenario

  1. The boss calls: The performance of our system is lousy.
  2. Look at the logs

    And if it isn't.

  3. Turn on one or more logs that were turned off

    And if it isn't.

  4. You now know whether the problem is where the boss thinks it is: i.e., inside a particular application.
  5. All this time you have been examining the application while it is `in service', because that's where the problem was noticed.
    Now you are going to start doing things that you can't try while the application is in service.
  6. Add instrumentation to the application by altering its source code.
  7. Find a more-instrumented version of the operating system
  8. Find a hardware monitor and put it on the system in the critical place

If you have identified the problem in steps 6-8 you will almost certainly want to test performance using new synthetic workloads.

Once you think the problem is solved you work your way back up this lists until you get to 1, which changes to `You call the boss.'


What I have called a log is usually called a trace, which is

Practical Issues

The nature of logs

Tools for looking at logs


The code inserted to generate traces.


What other reasons might you have for wanting to measure performance?

What do we try to measure?

  1. Arrival and departure times of requests
  2. Processor activity, which should be correlated with service times
  3. Other resource activity, particularly NICs
  4. Failures

Levels of Measurement

  1. Application code
  2. Profiling tools
  3. Operating system
  4. Kernel
  5. Hardware

The Big Question

How much does the introduction of monitoring software influence the performance of the application.

  1. Event-driven monitors
  2. Sampling monitors

Return to: