Re: best effort vs. given req rate - strange response times

"Alex Rousskov" <[email protected]>
Newsgroups gmane.comp.web.web-polygraph.user
Organization The Measurement Factory
Message-ID <[email protected]>
On Mon, 2005/02/14 (MST), <[email protected]> wrote:

> I am currently implementing a secure HTTP proxy for an information
> security laboratory (see http://www.infsec.ethz.ch/lab/appliedlab) and
> use web polygraph for performance testing. I want to test the proxy's
> performance a) with a realistic low request rate of .6 req/sec and b) in
> best effort mode.
> ...
> the actual test consist of a single phase during 20 minutes. I ran the
> test with different configurations of the proxy (filtering modules
> switched on or off) but always encountered a very strange behaviour:
> mean response times are _lower_ in the best effort mode than with the .6
> req/sec request rate...
>
> example from one test:
>
> best effort: 180 xAct/sec = 13.65 Mbits/sec, mean response time 5msec
> .6 req/sec: 0.60 xAct/sec = 0.05 Mbits/sec, mean response time 9 msec

There are several differences between the two tests that may explain lower  
best effort response time. For example, with a single best effort robot,  
the proxy handles one request at a time. There are no concurrent requests  
(except for requests for embedded objects, if they exist in your  
environment). With a constant mean request rate robot, you may get bursts  
of concurrent requests. The proxy might slow down responses during a  
burst. To [indirectly] verify this theory, study the "Concurrency Levels"  
graphs produced by the "reporter" tool and increasing the number of  
best-effort robots to match the concurrency level of the other test.

Another reason could be the mean rate of transactions itself. It is  
possible that something in the proxy slows down isolated transactions  
compared to transactions that occur without a delay. For example, the  
proxy may have some kind of select(2) or idle loop optimizations that lead  
to a few milliseconds of extra sleep time when a new transaction arrives  
after a pause. Polygraph might have a similar problem as it is rarely used  
for very low request rate testing. To [indirectly] verify this theory, you  
can increase the number of rated robots or increase the single robot rate  
to ensure that there is usually a few pending requests at the proxy.

Note that the difference within a few milliseconds is usually within  
Polygraph test precision. A consistent difference most likely indicates  
that there is something interesting going on, but any two comparable  
results are still a statistical tie.

It would be great if you inform the list of your progress and, hopefully,  
the actual reason behind response time difference.

Thank you,

Alex.
P.S. You can further simplify the test by removing embedded objects, but  
that would be a less realistic, micro-level test, of course.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.