RE: Tests settup for MDC1

[Arie Shoshani <arie@math.lbl.gov>]

> > 1.  Tests will be conducted in two configurations:
> >      a) A stand alone Storage Manager exercised by the INQ_EI test tool
> >          (Objectivity is also not involved).
> 
> Does this test move the data files or is it really just testing
> the index?

This test moves the files.
 

> > 3)  To make the length of time realistic we think that it should be
> > proportional to the number of events in a file.  There will be two
> > methods of doing that:
> >       a) a fixed parameter per event that we can vary for each test
> >            (e.g. 1, 30, 1000 sec - corresponding to different analysis
> > types:
> >            Hadron, event-by-event, etc.)
> 
> The range 1-1000 sec/event is about right for STAR, large events.
> To simulate small STAR events or other experiments the time/event
> should be able to go below 1 sec.  I.e., don't use integer seconds
> for this time, either floating point or integer milliseconds.

Good point.


> > In addition to measuring performance, we hope to discover with the above
> > controlled experiments the bottleneck in the system for various query
> > mixes.  If the event processing time is very small, we will expect the
> > caching of files from tape to be the bottleneck.  If the event
> > processing is very long, we expect the cache size to be the bottleneck. 
> > It will be interesting to find the event processing time that balances
> > the two.
> 
> I think the issue of one vs. two tape drives is important and relevent to
> most measurements, so you need to consider when these measurements
> can be made.

That is what we hope to see: if reading from tape is the bottleneck, then
two (or more) drives would be desired.

> > Another test we may want to do (if we have the time) is to launch lots
> > of queries (100-1000) simultaneously to test the robustness of the
> > system, and perhaps the performance of Objectivity in such cases.
> 
> For "real" queries with star or phenix analysis code running we will
> probably hit memory limits before getting 100 queries on rmds03.
> I do think it is good ro run the number of queries up to the point
> things fall apart tho.

We can run a large number with fake code (i.e. introduce time delays
to simulate analysis time) so that we can check large number of queries.