Introduction
This document describes the initial plan for IFS performance
and interoperability testing at Notre Dame. Performance testing is necessary
to developing a level of expectation from the service. By studying a system
in a controlled environment and then again "in the wild", that
system's overall impact can be estimated. This leads to being able
to make informed decisions by eliminating guesswork as the system scales
to meet demand. Also, it helps set the critereon with which to choose
a particular solution in the first place.
Questions
- Why won't migrating users from AFS to CIFS help network performance?
- What is the current protocol distribution on the network?
- How will the new IFS implementation (and other projects) affect the
protocol distribution?
- What is the current netowork topology (network map, router/switch/hub
models and port speeds, etc...)?
- How much traffic does a typical user generate now (data characterization)?
- How much traffic will a typical user generate with new IFS implementation?
- What is the current network performance level (Quantify: e.g. how
long to do: file create, open, copy, delete, etc...)?
- What is the baseline performance level (Quantify: e.g. same as above,
but on isolated segment)?
- How significant is client hardware (CPU, memory, cache, disk, NIC)
with regards to performance?
- How significant is server hardware (CPU, memory, cache, disk, NIC)
with regards to performance?
- How do similar tasks compare when performed in AFS, CIFS, AFP (bandwidth,
performance, etc...)?
|