Am 14.02.19 um 12:00 schrieb Aleksandar Lazic:
>> I am successfully able access brotli compressed URLs with Google Chrome,
>> this requires me to disable `gzip` though (because haproxy prefers to
>> select gzip, I suspect because `br` is last in Chrome's `Accept-Encoding`
>> header).
> Does it change it when you use `br` as frist entry in `compression algo ... `

I tried that. It does not. In the absence of a q-value for the encoding
HAProxy select the first value listed in the Accept-Encoding header. I
just checked RFC 7231#section-5.3.4 which does not specify a priority in
this case. Maybe the code should be changed to use order of the
algorithms in the config to determine the priority when the client gives
equal priorities.

>> I also am able to sucessfully download and decompress URLs with `curl`
>> and the `brotli` CLI utility. The server I use as the backend for these
>> tests has about 45ms RTT to my machine. The HTML page I use is some random
>> HTML page on the server, the noise file is 1 MiB of finest /dev/urandom.
>> You'll notice that brotli compressed requests are both faster as well as
>> smaller compared to gzip with the hardcoded brotli compression quality
>> of 3. The default is 11, which is *way* slower than gzip.
> How much more/less/equal CPU usage have brotli compared to gzip?

I did not check, because I would have to build something more elaborate
than "look at curl's output" for that. Also I have no idea how I would
do so. I'll leave this up to the experts :-)

> I'm a little bit disappointed from the size point of view, it is only ~6K less
> then gzip, is it worth the amount of work for such a small gain of data 
> reduction.

Even 6kB add up over time. Especially on cellular networks. Also I did
not tune all the brotli encoder knobs yet. As an example one could
specify that the contents is UTF-8 encoded text which possibly improves
compression rate further (I guess it selects a different dictionary):

Best regards
Tim Düsterhus

Reply via email to