fiber: 🐛 [Bug]: ≈500ms Performance penalty using compression on and 'br' in 'Accept-Encoding'
Bug Description
Usually I by default set compression to 2 but today I noticed a problem when on fiber v2.51.0.
This is the config I use:
app.Use(
compress.New(compress.Config{
Level: 2,
}),
)
I tested a bit and came to this conclusion:
- direct call/access (about 5ms)
- Nginx Proxy call (≈400-600ms)
a direct call will always be fast, but as soon as I access a fiber 2.51.0 pages I see TTFBs of at least 400-600ms.
This penalty just appears to be happening on the HTML part, not any static assets. Turning off compression solves the problem entirely.
So I had multiple thoughts:
- the user the docker container runs with does not have permission to write the compressed file and therefore takes long, but I discarted this thought, as this would also have to affect the direct call - which it does not.
- I tought about have a wrong ProxyHeader and did some tests there, as there might be some different behaviour behind NPM (Nginx Proxy Manager) but also all of these tests did not lead to anything.
- This must be related to 2.51.0 as it just appears there.
- disableing compression fixes the problem entirely
- had a look at the changelog of 2.51.0, sounds like this changed some behaviour to upstreams/proxies: https://github.com/gofiber/fiber/pull/2678
How to Reproduce
Actually already described above
Expected Behavior
New features can have a performance penalty, but 400-600ms is not acceptable I guess?
Fiber Version
v2.51.0
Code Snippet (optional)
No response
Checklist:
- I agree to follow Fiber’s Code of Conduct.
- I have checked for existing issues that describe my problem prior to opening this one.
- I understand that improperly formatted bug reports may be closed without explanation.
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 25 (12 by maintainers)
Via Discord the problem could be locally reproducts, but it just seems that Compression-Level 2 (brotli lvl9 LINK) ist just very CPU intense and takes much longer than other compression techniques on theirhighest level.
So even if a single request took about 0.5s, this is to be expected when using brotli on its highest level, combined with some 100kb of text.
@ReneWerner87 thank you for the clearification! @nickajacks1 thanks for the quick reproduction of the error and participation
P.S.: just don’t use compression level 2 in the
compress.Config😉Actually, I found a similar behavior on the above snippet I shared, but it still occurred as far back as v2.40.0. When I get the html page through a browser, there is a several hundred millisecond delay before the first byte:
If I refresh right away, there is no delay, but if I wait a few seconds and refresh, the delay occurs again.
The delay does not occur if I use curl.
Using Express, the delay occurs on the first connection, but never again.
The connection is happening from windows to WSL (fiber) in my case.
I don’t know enough about what a browser does on an HTTP get to know if this is the same thing you were experiencing or not, but indeed the same Initial Connection is very short when I connect to your example links.
