In my various performance tests with Squid, I observed that cache size affects peak throughput. More specifically, I feel that a half-empty UFS filesystem performs better than a full one. When the filesystem is full, it takes longer to find free inodes, to delete files, etc.

With the traditional Polygraph tests, throughput is an input parameter. That is, you measure response time and hit ratio for a given throughput. This makes it awkward to compare different configurations if you don't know what the peak throughput is going to be.

For these tests, we modified Web Polygraph version 2.5.4 to support a ``constant response time mode.'' In this mode, Polygraph increases or decreases the offered load if the response time goes below or above defined thresholds. Polygraph calls this feature rptmstat. We used the following parameters: 

Phase phFill = { 
	...
        rptmstat.load_delta = 5%;
        rptmstat.sample_dur = 60sec;
        rptmstat.rptm_min = 2.75sec;
        rptmstat.rptm_max = 3.00sec;
	...
};

Phase phRptmLevel = { 
	...
        rptmstat.load_delta = 5%;
        rptmstat.sample_dur = 60sec;
        rptmstat.rptm_min = 1.50sec;
        rptmstat.rptm_max = 1.75sec;
	...
};

The workload is similar to PolyMix-3, except the top1-dec2 phases are replaced with a single rptmLevel phase, which lasts 12 hours.

Even though offered load is no longer constant, we still need to specify a ``peak'' load so that Polygraph knows how many robot and server agents to create. This may create a strange situation where we create enough robots to generate 400 TPS under a regular PolyMix-3 workload, but the actual throughput is only 100 TPS. In other words, there may be a performance difference for 1000 robots totalling 100 TPS compared to 250 robots totalling 100 TPS. For example, 1000 robots probably uses more (persistent) connections than 250 robots.

Results

We ran these tests on three different Squid boxes: