You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One idea is to use Spreads.IPC/Aeron to write and read values into a IPC channel and then process them on Spreads side. Then we will measure correct response time. Run an elevated GC-free proc with a precise timer (e.g. volatile incrementing long counter or performance counter) in a separate thread. That would be a realistic test for data arriving -> processed -> returned.
Good news is that most focus so far was on throughput, latency percentiles were just to understand orders of magnitude.
An eye-opening talk by Gil Tene. We already use HDR Histogram but need to make sure GC doesn't pauses result collection. https://www.youtube.com/watch?v=YpBwt-rO07o
One idea is to use Spreads.IPC/Aeron to write and read values into a IPC channel and then process them on Spreads side. Then we will measure correct response time. Run an elevated GC-free proc with a precise timer (e.g. volatile incrementing long counter or performance counter) in a separate thread. That would be a realistic test for data arriving -> processed -> returned.
Good news is that most focus so far was on throughput, latency percentiles were just to understand orders of magnitude.
Upd. Same talk, another version: https://www.infoq.com/presentations/latency-response-time
The text was updated successfully, but these errors were encountered: