On Wed, 2 Jun 2004, senthil wrote:
> I tried configuring the polymix test for 2000 urls.
> This was my setup.I used 4 client-server pairs with the
>
> "TheBench.peak_req_rate = 2000/sec;
>
> in all the client and server polymix-4.pg files and also in
> the DNS system.Each client will generate a maximum of
> 500 req/sec and hence 4 pairs should generate 2000 req/second.
>
> I could not complete the test as polymix ran out of memory
> and the test ended abruptly.I went through the FAQs in the site
> and the reason said is that the cache is not fast enough to respond
> to polymix.
> These are my queries::
>
> 1.Can i avoid the running out of memory situation by increasing
> the number of client server pairs??
Think of this problem as a swimming pool that gets some water
(requests are queued) and drains some water (requests are served) at
the same time. If cache is not responsive enough, the pool will
overflow.
Will a larger pool avoid the problem? That depends on how much extra
water you have to accommodate until the end of the test. If you test
dies early in the test, more client/server pairs are unlikely to help
(i.e., the request queuing rate is too large to be offset by a
reasonable number of client/server pairs).
Moreover, even if more client/server pairs allow you to complete the
test, cache response time measurements ought to be pretty bad (or the
requests would not be excessively queued). In most cases, bad response
times are equivalent to a dead test: both indicate that the cache
cannot handle the load.
> 2.Is there any parameter i can change in polymix setup such that it
> can wait for longer time for the cache to respond and hence the
> running out of memory situation can be avoided?
First of all, have you verified that your bench can handle 2000
req/sec without the cache? It is not uncommon for the bench to be the
bottleneck at higher request rates when bad Ethernet switches, bad
cables, or configuration errors slow things down. To verify, run a
no-proxy test at 2000 requests per second (clients making DNS requests
and talking directly to the servers). I will assume that your bench is
not the bottleneck.
If the test dies in the fill phase, consider lowering the fill rate.
Some caches cannot fill at the peak measurement phase. All should be
able to fill at 50% of that and many will fill fine at 75%.
If the test dies after the fill phase, you have to ask yourself why
you are running these tests:
- If you want to measure PolyMix-4 performance (to compare
with other caches, etc.), then you should just
adjust peak and fill request rates. Adjusting other
parameters moves you out of PolyMix-4 space and makes
your workloads/results non-PolyMix.
- If you want to measure cache performance at 2000 requests
per second, then you can create a custom workload that
keeps the cache happy at that load level. There are many
knobs you can turn to do that. For example, you can
decrease server-side delay (xact_think) and/or decrease
response sizes. However, a "find any workload that does
2000/sec" approach seems unreasonable to me. If 2000/sec
is the goal, you probably have other conditions to
satisfy (perhaps coming from a client trace, etc.). If so,
you should use those conditions to shape your workload in
a realistic fashion.
- If your goals are other than the two common ones above,
please specify them so that we can assist you better
To summarize (and assuming the bench itself is not the bottleneck, and
the cache fills just fine), your current result tells you that the
cache cannot do 2000 PolyMix-4 requests per second. What to do next
depends on your actual testing goals.
HTH,
Alex.
-- Protocol performance, functionality, and reliability testing. Tools, services, and know-how. http://www.measurement-factory.com/
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:27 MST