⏲ Long-running tasks blocking the WebSocket process

[programarivm]

One of the advantages of using open source software is that almost everything is done publicly.

As you may probably know, at some point it was decided to rewrite the API endpoints in the chesslablab/chess-api repo in the form of WebSocket commands in the chesslablab/chess-server. The reason being was mainly because this setup looked simpler and cheaper.

• WebSocketization of the API endpoints chess-server#311

😅 However, whether using Workerman or Ratchet, the staging server has demonstrated that there is something wrong with this setup. The current WebSocket server is pretty much unusable if there are a few users connected at the same time.

• Long-running tasks blocking the WebSocket process walkor/workerman#1058
• Long-running tasks blocking the WebSocket process

Stay tuned!

[programarivm]

This is expected behavior for Node.js as well. Remember, don't block the event loop.

• Don't Block the Event Loop (or the Worker Pool)

The Event Loop notices each new client connection and orchestrates the generation of a response. All incoming requests and outgoing responses pass through the Event Loop. This means that if the Event Loop spends too long at any point, all current and new clients will not get a turn. You should make sure you never block the Event Loop. In other words, each of your JavaScript callbacks should complete quickly. This of course also applies to your await's, your Promise.then's, and so on.