[squid-dev] [PATCH] Increase request buffer size to 64kb

[Alex Rousskov]

On 03/29/2016 10:39 PM, Nathan Hoad wrote:
> On 30 March 2016 at 12:11, Alex Rousskov
> <rousskov at measurement-factory.com> wrote:
>> On 03/29/2016 06:06 PM, Nathan Hoad wrote:
>>
>>> This (very small) patch increases the request buffer size to 64kb, from 4kb.
>>
>>> -#define HTTP_REQBUF_SZ  4096
>>> +#define HTTP_REQBUF_SZ  65535
>>
>>
>>> In my testing, this increases throughput rather dramatically for
>>> downloading large files:
>>
>> Based on your results alone, it is clear that the patch does more than
>> "increases the request buffer size"(*). IMO, the important initial
>> questions we need to answer are:
>>
>>   1. Why the performance is improved in this micro test?
>>   2. What are the expected effects on other traffic?

> I think these are reasonable questions to ask. Answering question one
> will take time

Yes, finding the correct answer may not be trivial, although I would
expect that larger system reads result in fewer reads and, hence, less
Squid-imposed overhead in a micro test. That hypothesis should be
relatively easy to semi-confirm by looking at the number of system reads
before/after the change (if that statistics is already reported).
Hacking Squid to collect those stats should not be difficult either (if
that statistics is not already reported).


Another related angle you may want to consider is comparing 8KB, 16KB,
and 32KB performance with the already available 4KB and 64KB numbers:

*  If performance keeps going up with a larger buffer (in a micro test),
how about 512KB? You will need a large enough file and a fast
client/server to make sure Squid is the bottleneck, of course.

* If there is a "sweet spot" that is determined by system page size or
perhaps NIC buffer size, then one can argue that this parameter should
be configurable to match that size (and perhaps even set based on system
parameters by default if possible).

Also, as you look at the code you may be able to tell others whether
Squid always uses a fixed buffer or grows the buffer as needed. If Squid
does not grow the buffer, perhaps it would be easy to hack it to grow
the buffer during a micro test. That "adaptive algorithm" may allow us
to avoid changing the default while accommodating "fast download"
environments.


> I'm not sure how I can answer question two definitively

I recommend starting with "bzr grep HTTP_REQBUF_SZ" or equivalent. If
you are lucky, the number of actual uses will be small and you will be
able to speculate about their impact and/or isolate it to avoid that
speculation (and to allow separate configuration in the future).


> - are there
> any accepted benchmarking/test suites I can use to test the change on
> different types of traffic, to see if particular situations have been
> negatively affected?

There are benchmarks (e.g., Apache ab and Factory Web Polygraph) and
even "standard" workloads, but if you are asking about their existence,
it implies that it will take you a while to get _meaningful_ results
using those tools. I would start with manual code analysis instead (as
mentioned above) and then decide whether additional testing is warranted
(and what kind of testing would be best).


> Yes I think you are right in that the constant may be
> misnamed/misused. Once I've gone through all the places that use it, I
> suppose reevaluating its name would be a good idea.

... and we would have to rename it anyway if we decide to make it
configurable. Knowing where it is used (and/or isolating its usage)
would be important for that as well.


Thank you,

Alex.