Changes

Jump to: navigation, search

SPO600 Baseline Builds and Benchmarking Lab

768 bytes added, 14:40, 11 January 2016
no edit summary
[[Category:SPO600 Labs- Retired]]{{Admon/lab|Purpose of this Lab|In this lab, you will do a baseline build of a software package and benchmark its performance.}}{{Admon/important|This lab is not used in the current semester.|Please refer to the other labs in the [[:Category:SPO600 Labs|SPO600 Labs]] category.}}
== Lab 2 ==
 
=== Prerequisites ===
# Obtain the software (via git or other version control system if necessary, or by downloading the appropriate archive/tarball).
# Do a baseline build. You may need to install build dependencies.
# Decide what you're going to benchmark and how you're going to do the benchmarking. Some programs may come with test suites, test harnesses, or exercisers (dummy clients) that are appropriate for benchmarking, while in other cases you may need to create your own test harness or exerciser program/script. In some cases, you will want to measure execution time, in other cases, some measure of performance (e.g., throughput). Make sure you control the appropriate factors, test for repeatability, and document the benchmark conditions so that the results can be reliably reproduced in the future. Most of these programs are complex, and different aspects or features of the program could be benchmarked (e.g., static content via http, static content via https, or CGI content under Apache httpd) - select one clear area for examination.# Execute your benchmarking plan and record the results.With your results, include everything that may affect the benchmark results: the version of the operating system, libraries, and toolchain (compiler, linker, etc); the system specifications and configuration; the version of the software you built and benchmarked; and so forth. These commands ''may'' be useful: lshw free cat /proc/cpuinfo cat /etc/*release* rpm -qa hdinfo cat /proc/mdstat pvs vgs lvs
{{Admon/tip|Share the Wealth|Make sure that each member of the group has access to the files the group was working on before the end of class (e.g., put them in a folder with world-readable permissions, post them on a public URL, or mail them to each member of the group). It would also be a good idea to share contact information within the group.}}
# Complete any of the tasks not completed by the group during the class.
# Analyze the results. Look for repeatabile, consistent results. Understand the limitations of the benchmark results you obtained.
# Blog your benchmark configuration (system, build options, toolchain versions), your results, your analysis of the results, and your experience doing this lab, including things that you learned and unanswered questions that have come up.

Navigation menu