Mastodon input buffer

gistfile1.txt

The task of sending messages / "toots" is delegated to background processing, 
so whenever a new message "toot" is received by the server, it is added to a queue. 
There is another thread/process that asynchornously reads from that queue and dispatches all these messages / "toots" to target users.
There is yet another thread/process that takes that dispatched messages and using WebSocket updates timelines 
inside of visitors' browsers in real time.
When you run those 5 threads what you have mentioned, the side was not responding (i.e. hanging) because your 
browser could not keep up with interpreting and displaying all those WebSocket updates. 
In real live a single end user operating a single browser don't have this problem because 
he doesn't receve such big amount of messages / "toots".
I observed how server behaves when 7 threads of the java seeder are being run against it and there was 
not even a problem with emptying the queue as all the background jobs were being 
picked end executed instantly, so when I stopped the java seeder threads, in the same second the queue was empty.