Blocks queue

[bararchy]

target	direct	repeater
www.neuralegion.com	5.4 req/s	0.3 req/s
owasp benchamrk	104.6 req/s	1.0 req/s

We need to figure out how to manage a faster event bus to cater to more requests.
Old crystal based repeater managed ~60Rps when I tested.

[derevnjuk]

@bararchy EventBus implements a regular RPC. It ensures reliably handle messages but blocks queue while performing a request.

I performed 5 tests which sent by 1000 requests with the following payload to development.playground.nexploit.app:

{
  "method": "GET",
  "url": "https://development.playground.nexploit.app/"
}

#	Pattern	req/s
1	Direct (async)	281.7
2	RPC current	1.4
3	Pub/Sub previous implementation	71.1
4	Queue per request (RPC)	77.7
5	Direct reply-to (RPC)	73.4

As you see 3, 4 and 5 implementations are much faster than 1 (regular RPC). But there're a few issues:

• Pub/Sub: it doesn't guarantee delivery event. You need to close the consumer after the reply and requeue unexpected messages.
• Queue per request: it is too expensive from a memory usage perspective
• Direct reply-to: that same RPC, but requires no-ack mode. It will affect on latency if customers start multiple scans.