for one my ticket about use encoding during cache warm up I receive answer:
by reviews, brotli more faster than gzip and from 14% to 40% better compression (especially for JS/CSS)
brotli supported by all modern browsers
and that's why more interesting this part:
if a client only accept br, not gzip, lsws will dynamically convert to br and serve. when request multiple times, lsws will save the generated br copy to lscache, will not save the extra copy when only requested once.
but my questions about: how many times from "request multiple times" are multiple? after how many only br requests lsws save br copy to lscache?
two? three? five? ten?
still not answered
may be anybody know and have statistics about how many only br request need?
P.S.
this is the official clarification from web server team:
When a dynamic page save to lscache.
if it's uncompressed, it will save as is.
When a browser request, it usually has accepted gzip, br, lsws will convert the plain text to gzip, save a gzip copy to lscache, and serve. and original uncompressed copy will be removed. we do not save uncompressed copy in lscache to save space, which has rarely usage.
If it's gzip, it will save as is.
when a browser request, lsws will serve gzip copy directly.
when a client request, only accept deflate, then lsws will dynamically decompress it, and serve the uncompressed copy
if a client only accept br, not gzip, lsws will dynamically convert to br and serve. when request multiple times, lsws will save the generated br copy to lscache, will not save the extra copy when only requested once.
so I think, only there are multiple browser request with only "br" accept coding header will cause lsws generate a br cache copy. since our crawler only request one time, so even with "br" CURLOPT_ENCODING will not generate a br compression cache copy.
When a dynamic page save to lscache.
if it's uncompressed, it will save as is.
When a browser request, it usually has accepted gzip, br, lsws will convert the plain text to gzip, save a gzip copy to lscache, and serve. and original uncompressed copy will be removed. we do not save uncompressed copy in lscache to save space, which has rarely usage.
If it's gzip, it will save as is.
when a browser request, lsws will serve gzip copy directly.
when a client request, only accept deflate, then lsws will dynamically decompress it, and serve the uncompressed copy
if a client only accept br, not gzip, lsws will dynamically convert to br and serve. when request multiple times, lsws will save the generated br copy to lscache, will not save the extra copy when only requested once.
so I think, only there are multiple browser request with only "br" accept coding header will cause lsws generate a br cache copy. since our crawler only request one time, so even with "br" CURLOPT_ENCODING will not generate a br compression cache copy.
by reviews, brotli more faster than gzip and from 14% to 40% better compression (especially for JS/CSS)
brotli supported by all modern browsers
and that's why more interesting this part:
if a client only accept br, not gzip, lsws will dynamically convert to br and serve. when request multiple times, lsws will save the generated br copy to lscache, will not save the extra copy when only requested once.
but my questions about: how many times from "request multiple times" are multiple? after how many only br requests lsws save br copy to lscache?
two? three? five? ten?
still not answered
may be anybody know and have statistics about how many only br request need?
P.S.
OLS only do gzip for cache, LSWS can store cache in both gzip and BR when needed, gzip is preferred as all browsers support it.
For ESI, LSWS never create BR copy. for regular cached page, it may create BR copy on the fly when a lot requests want BR.
For ESI, LSWS never create BR copy. for regular cached page, it may create BR copy on the fly when a lot requests want BR.
Last edited: