Your game_logs queue should be quite full still. It's an unhealthy queue because it grows faster than it can be consumed. This is dangerous because it can lead to the system running out of memory or disk space. If Rabbit goes down, your whole system goes down with it.
A healthy queue is an empty queue.
Most of the time a healthy cluster, even if it's processing thousands of messages per second, will have mostly empty queues. You always want to be able to consume messages as fast as they can be published.
In this case, we have a slow application (the peril "server") that can only process one message per second. Let's scale it up to 100 instances to see if we can empty the queue.
I provided a script at src/scripts/multiserver.sh. We will run it with 100 as the argument to start 100 peril servers.
Before we do that, we need to make sure that the src/server/index.ts detects non-interactive mode.
// Used to run the server from a non-interactive source, like the multiserver.sh file
if (!process.stdin.isTTY) {
console.log("Non-interactive mode: skipping command input.");
return;
}
./src/scripts/multiserver.sh 100
Watch the game_logs queue in the web UI. You should see 100 consumers connect to the queue, but if you watch the "consumer ack" stat, you might notice that you're not getting the 100 message/second that you expected. Kill the script with ctrl+c (which should kill all the peril servers).
The reason has to do with prefetch... one of our consumers is caching all the messages locally before the other consumers can get them. We'll fix that in the next lesson, you can move on.
Become a member to Complete