fix!: better cache memory usage

[dunglas]

• Migrate from archived https://github.com/kevburnsjr/skipfilter to https://github.com/dunglas/skipfilter
• Migrate from golang-lru to Otter for better performance
• Migrate from hash/fnv to github.com/cespare/xxhash/v2
• Hashers pool
• Bump deps

Closes #1024.

[naxo8628]

Hi @dunglas, thank you so much for looking into this and creating the PR! I'd be happy to test these changes in my environment. Is there a pre-built Docker image available for this pull request that I could use?

I'm new to Go and I'm trying to compile the project and then build a Docker image.

First, I compiled the binary with:
go build -o mercure ./cmd/mercure/

Then, I built the Docker image using:
docker buildx build --platform linux/amd64 -t myrepo.../mercure:test-cache . --push

However, when the pod starts up, it fails with the following error:
exec /usr/bin/caddy: exec format error

Any help would be appreciated. Thanks!

[naxo8628]

@dunglas Solved! I've never used goreleaser.

I've deployed this version to the staging environment, and it will go to production tomorrow. I'll provide you with performance metrics after that.

[naxo8628]

Hello,

The deployment has been running for over 12 hours in our prod environment, and the results are better. I'm attaching a performance graph that clearly illustrates the difference before and after deploying the fix. The vertical line marks the deployment time.

Let me know if you need some debug profiles or more metrics (like subcribers_conected/ update_total...).

Overall, this fix is a huge success and resolves the critical performance issues. Thank you for your work on this! ❤️

[dunglas]

Here is a benchmark I ran locally:

SUB_TEST_CONCURRENCY=500 SUB_TEST_TOPICS=100 SUB_TEST_MATCHPCT=70 go test -benchmem -run='^$' -count 6 -bench '^BenchmarkLocalTransport$'
benchstat old.txt new.txt
goos: darwin
goarch: arm64
pkg: github.com/dunglas/mercure
cpu: Apple M1 Pro
                                                         │       old.txt       │               new.txt               │
                                                         │       sec/op        │       sec/op        vs base         │
LocalTransport/100-topics:500-concurrency:70-matchpct-10   107.96µ ± 16687715%   96.89µ ± 30112408%  ~ (p=0.065 n=6)

                                                         │       old.txt       │                   new.txt                   │
                                                         │        B/op         │         B/op          vs base               │
LocalTransport/100-topics:500-concurrency:70-matchpct-10   37.60Ki ± 74880960%   22.27Ki ± 209187700%  -40.79% (p=0.026 n=6)

                                                         │       old.txt       │                  new.txt                   │
                                                         │      allocs/op      │      allocs/op       vs base               │
LocalTransport/100-topics:500-concurrency:70-matchpct-10   31.00 ± 1100182848%   22.00 ± 2566207586%  -29.03% (p=0.015 n=6)

[dunglas]

Thanks @naxo8628. This indeed looks way better. I'm still interested in a profile, if possible.

Thank you.

[naxo8628]

@dunglas I've just deployed to production with debugging enabled, as I wanted to wait at least 24 hours before the next deployment. I will send performance profiles within the next 48 hours.

In any case, although the last deploy improved the initial memory spike, it seems the memory fills up again after a few hours.

[dunglas]

@naxo8628 could you copy your Mercure config? I'm especially interested in write_timeout.
I would also be interested in knowing if the number of subscribers is growing over time or not.

Thanks!

[naxo8628]

@dunglas
Memory consumed & subscribers connected in last 34 hours :

Added heap & allocs:
pprof.caddy.alloc_objects.alloc_space.inuse_objects.inuse_space.003.pb.gz
pprof.caddy.alloc_objects.alloc_space.inuse_objects.inuse_space.004.pb.gz

This is the values.yaml of the chart (write_timeout is set to 7200s)

mercure_dunglas.yaml