Event loop blocked by too many executions about graphql-redis-subscriptions HOT 1 CLOSED

Hey @Shahor!

As far as I understand it, this package could not be the issue as it will only tackle those 500 messages sent to the node instance from Redis. Those messages will be accumulated in an AsyncIterable and then read and executed by the subscriptions server.

In order to be sure I'd have to dig in on your repo. Is there any more information that you've discovered since opening the issue?

Regardless, I suspect that the problem you are facing is inherent with how subscriptions-transport-ws reads each event from the AsyncIterable and the limitations of a single node process while sending information over a web socket.

As you can see here https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/server.ts#L373 the server uses forAwaitEach which will wait for the next event to be pushed into the iterable.

Basically, in your scenario, you've created 300 subscribers that are waiting to get a new message.
When the first message arrives, the server will start formatting and pushing those messages down each of the 300 open channels and while those are not synchronous work, it will choke the event loop quite easily.

These kinds of issues are actually the reason why I've created this library, to allow for horizontal scaling on the servers doing the execution work.

The thing that does not make sense and could definitely be an issue, is that you saying that the filter returns false and still it does not decrease the amount of work the server deals with... Unless the whole pressure does not come from there.

I'll try running the thing myself and see if I arrive at any conclusion but thanks for raising that up.

from graphql-redis-subscriptions.