ruby - Seeing long delays due to EventMachine quantum – how can I speed things up? -

i developing real-time application using eventmachine. 2 clients, a , b, connect eventmachine server on standard tcp, or via websocket em-websocket.

every time data goes through eventmachine, code execution takes 95ms hit. when a talks server, there 95ms delay. when a talks b, there 190ms delay.

if many requests occur in rapid succession, delay disappears, except final request in sequence. so, if send 10 rapid requests, i'll 9 responses after 5ms each, 10th response take 95ms again.

i've deduced has eventmachine.set_quantum. docs:

method: eventmachine.set_quantum

for advanced users. function sets default timer granularity, default slightly smaller 100 milliseconds. call function set higher or lower granularity. function affects behavior of add_timer , add_periodic_timer. applications not need call function.

avoid setting quantum low values because may reduce performance under extreme conditions. recommend not use values lower 10.

well, explains 95ms came from. sure enough, delays change calling eventmachine.set_quantum, wary of tweaking value because of warning in documentation.

what set_quantum doing? can't find documentation or explanation quantum variable means.

what can reduce these delays? i'd understand potential repercussions of decreasing quantum to, say, 10ms.

is eventmachine right choice? i'm using glorified tcp connection. maybe should stick raw sockets inter-process communication, , find websocket server gem doesn't use eventmachine.

eventmachine running loop, checks:

1. whether timers got triggered.
2. if of file descriptors have them.

the second step involves appropriate mechanism under hood, e.g. select(..) call. quantum value goes. loop looks rather this:

1. any timers triggered?
2. any of file descriptors have them? wait them, quantum millis.
3. unless there's shutdown request, go 1st step.

therefore setting quantum lower values make loop iterated more often, eating cpu cycles. don't think issue though.

what surprises me have communication delay @ all, since of querying mechanisms (select, or epoll, or whatever) return if there's event (e.g. data) on file descriptor. means shouldn't incurring delays @ all. , if delay design, numerous thin users would've been pretty upset it.

all of makes me think there not right in code makes work way. unfortunately, can't tell more unless see it.

hope helps!