Re: 2500urls/sec and 150 Mbits throughput
Alex Rousskov <[email protected]>
| Newsgroups | gmane.comp.web.web-polygraph.user |
|---|---|
| Message-ID | <[email protected]> |
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/