On Mon, 2007-06-04 at 20:10 +0800, Leon Xiang Li wrote:
> Thank you for your help. Today I setup the polymix4 to test. But I meet
> the weird error :
>
> ../../src/runtime/IOBuf.h:37: assertion failed: 'theInOff <= theCapacity'
> in server side. The whole log and configuration file is enclosed.
This is most likely a bug in the 3.0 version you are using. Try v2.8
instead. The development version (available to the project sponsors) has
the bug fixed.
> And I still have several question:
>
> 1. How can I tell whether how many paires client/server can give enough
> pressure to my squid?
The number of pairs is determined by the peak rate. PolyMix-4 allocates
500 requests/second to each pair (modern PCs can pump more). What is
your proxy peak request rate? The answer to this questions is,
essentially, the purpose of the performance testing. If we could know
the peak rate a priory, we would not need to test!
There are many ways to find the peak rate. The simplest way is to repeat
tests until the peak is found, increasing the rate when the test fails
and decreasing the rate when the test succeeds. This is probably the
longest way as well.
Alternatives include running custom estimation workloads to approximate
the peak before running a long PolyMix test or two to validate
estimations. One such custom workload/approach is called "boiling frog".
You may want to search Polygraph web site for more information on that.
> 2. how long the test will last and how can I control it ?
The test is at least 11 hours long. Your test will be longer because you
need to fill the 21GB cache, which will take at least 4 hours at 200/sec
fill rate. Please see the URL below for details.
http://www.web-polygraph.org/docs/workloads/polymix-4/#Sect:3.1
You cannot control test duration without violating PolyMix rules (recall
that this workload was used during Factory cache-offs so it would be
wrong to leave test duration up to the tester). If you want to violate
the rules, you can shorten the measurement phases as well:
http://www.web-polygraph.org/mail-archive/users/200203/0004.html
Please note that some of the workload modifications are likely to make
results unreliable if not bogus. Proceed with extreme care.
HTH,
Alex.
Received on Mon Jun 04 2007 - 08:25:14 MDT
This archive was generated by hypermail 2.2.0 : Mon Jun 11 2007 - 12:00:08 MDT