Performance degradation over time

[progmancod]

Hi, first of all, congrats for your amazing project!

I noticed that every connection on the hub register a callback:

public function subscribe(callable $callback): void
{
    $this->init();
    $this->subscriber->on('message', function (string $channel, string $payload) use ($callback) {
        $callback($this->serializer->deserialize($payload));
    });
}

After the client close the connection, the callback remains there.

So, after few hours and hundreds of thousands of subscribes, the performance gets terrible, since every publish has to call hundreds of thousands functions, mostly unecessary (subscriber has long gone).

The solution is to listen connection e close events, register an array of subscribers (address => $callback()), and then remove them on connection close.

That's how the original implementation works: https://github.com/dunglas/mercure/blob/main/subscribe.go

[bpolaszek]

Hi @progmancod,

Thank you for spotting this! It makes sense indeed.

Problem is, Framework X doesn't seem to expose the Connection object, meaning we have no means to get notified when the connection closes. I'll try to get some help over there.

[bpolaszek]

Wait, after a coffee ☕ I think I found another way to address this, as the stream exposes a close event itself.
Can you please have a look at this and maybe try on your side?

[progmancod]

With 2 thousand users connected, after a few hours, freddie mercure continues to degrade performance. Maybe just hearing the "close" event of the "stream" is not enough in some scenarios. I'm concerned about the "error" and "end" scenarios.. Let's see the docs (https://github.com/reactphp/stream):

• The error event will be emitted once a fatal error occurs, usually while trying to read from this stream.

• The end event will be emitted once the source stream has successfully reached the end of the stream (EOF).

• The close event will be emitted once the stream closes (terminates).

• After the stream errors, it MUST close the stream and SHOULD thus be followed by a close event (OK)

• Many common streams (such as a TCP/IP connection or a file-based stream) will likely choose to emit this (close) event after reading a successful end event or after a fatal transmission error event. (Maybe the problem? will likely choose to emit?)

[bpolaszek]

Oh, that's bad news 🙁

Unfortunately, I'm quite overwhelmed these days, and I don't even have the time to perform a stress test.
I'll try to look at this ASAP, but I couldn't give any ETA at the moment.

[progmancod]

No problem, I'm trying to resolve the issue.

[bpolaszek]

Hey @progmancod - it's been a while this issue has been opened, and I wanted to make sure everything's now fine. I'm running Freddie on an intensive IoT platform (using Redis) and it can run during months without blinking an eye.

Do you mind if I close that issue?

[progmancod]

Unfortunately, the problem persists in our application. There are about 200 million posts per day, and within a few days, degradation occurs, forcing us to recycle the application. This change has helped a lot, tripling the time it takes for degradation to happen. But there's still some scenario I couldn't find:

$stream->on('close', fn() => $this->hub->unsubscribe($subscriber, 'close'));
$stream->on('end', fn() => $this->hub->unsubscribe($subscriber, 'end'));
$stream->on('error', fn() => $this->hub->unsubscribe($subscriber, 'error'));

[SimonFrings]

Hey @progmancod and @bpolaszek, I'm one of the maintainer of ReactPHP and Framework X and we recently received a ticket in ReactPHP's HTTP component, which sounds a little bit similar to the problem described hear (not 100% sure if it's related though). The problem was that the connection close handler wasn't cleaned up properly for each request, resulting in some memory growth.

This issue got fixed through reactphp/http#515 and was already released with reactphp/http v1.10.0. Like I said, I'm not sure if this is the same issue described in here, does the problem still persist with the new changes?

[progmancod]

Unfortunately, the problem persists, and we have given up on using the library in production after spending many hours investigating. Our application receives millions of hits per day, and performance degrades after a few hours. We have reverted to using the original library in Go.

[bpolaszek]

Hi @progmancod, no worries.
When you speak about performance degradation, what do you mean exactly? Memory leaks? High response times? Hub not responding?

[progmancod]

The memory increases slightly over time, but the main symptom is an ever-increasing slowness, until it becomes impractical under high demand.