On Thu, 12 Apr 2001, Lynn Scott wrote:
> ... However, since some of the benchmarking tests can take
> significant amounts of time, I was wondering if there was a way in
> which Web Polygraph could signal my process when it is done. I
> was thinking that perhaps the --notify paramter could work even
> though --notify is used in conjunction with polymon. Any ideas?
If properly configured, Polygraph processes quit when the test is
over. Thus, all you need to do is to write simple shell script:
polyclt .... # start polyclt process and block
signal-end.sh # run whatever commands you want to
# notify your process that the test is over
Using --notify option is probably not a good idea because (a) you do
not want to write code to parse notification messages, (b)
notification mechanism uses unreliable UDP, and (c) the messages do
not carry end-of-test information so you will have to rely on the
_absence_ of any messages to guess that the test is over.
> Also, another thing I need to do is monitor the round trip time (RTT)
> from polyclt, (a robot?), to the cache and then back again.
Response time measurements are available for hits (and misses). Use
Report Generator or lx to extract that information (hit.rptm.mean and
other hit.rptm.* objects). Mean response time for all transactions is
also reported run-time on the console and via polymon.
> I note that in the runtime statistics there is a column (I think
> column 5) for the replay rate (replies per second). How is the
> value derived?
rep.rate = number of replies received / interval duration
> Is there someplace where I can analyze what the single reply rate
For me, "reply rate" implies presence of at least two replies so I am
not sure what you mean by "single reply rate". It is possible to
extract response time of an individual transaction, but that would
> Also, is the reply rate done in consistent intervals, or do they
> just do another request after the completion of the previous
HTTP transactions from one robot may overlap (e.g., fetching an HTML
container and an embedded object). HTTP transactions from several
robots overlap often (robots are not synchronized with each other),
simulating realistic traffic from many isolated "browsers" or "users".
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:18 MDT