Hello,
I am currently using Gatling 2.1.7
I was trying to track down the origin of some message lost issues I was having with my websocket load test.
The websocket messages are “fire and forget”. The messages are sent but there is no ACK from the server under test.
When I ran the load test with a relatively high load (> 50000 req/s across 50 connections) I was finding that
the number of messages sent by Gatling didn’t match the number of messages received by my server under test.
I couldn’t see an obvious reason why the server could lose them so I tried the load test again but instead stopped by server
(kill -STOP ) to make the TCP buffers fill up to see if Gatling reported there was any problem. The TCP buffers on
both sides filled up immediately but Gatling reported no problems/no slowdown and kept stating that all messages were being
sent successfully.
Is that what is supposed to happen? The only way to test whether a message is really sent or not is by checking for the protocol level ack?
Or is there an option I am missing to make it pause/recognize when the TCP buffers full?
thanks in advance,
Gareth
I couldn't see an obvious reason why the server could lose them so I tried
the load test again but instead stopped by server
(kill -STOP <pid>) to make the TCP buffers fill up to see if Gatling
reported there was any problem. The TCP buffers on
both sides filled up immediately but Gatling reported no problems/no
slowdown and kept stating that all messages were being
sent successfully.
Mmmm, that's weird, because killing the process should send a FIN to the
clients, resulting in the connections being closed at some point.
Is that what is supposed to happen? The only way to test whether a message
is really sent or not is by checking for the protocol level ack?
Well, you're using WebSockets, so TCP ACKs wouldn't be a good fit: a
WebSocket frame could span over multiple TCP frames, or a single TCP frame
could contain multiple WebSocket frames.
Or is there an option I am missing to make it pause/recognize when the TCP
buffers full?
No, there's no such sanity check atm.
We could implement some back-pressure with some watermarks and only write
if we're below some limit. That's something we could consider for a next
version. This would have to be implemented in AsyncHttpClient first of
course.
Regards,
*Stéphane Landelle*
*GatlingCorp CEO*
slandelle@gatling.io