Hi,
I didn’t find any information about my concern in the documentation.
When I launch my simulation with 50 parallel sessions, gatling will generate ~5-6 mb/s of incoming internet traffic. I am interested in where does it come from and whether the internet speed limit will affect the simulation results if I will increase the parallel session number.
Best regards,
Andrei
Check that you don’t saturate your NIC.
Also, if you start suspecting something, check for GC rate if you start allocating too much objects (decoded responses) and GC slows you down.
Then, you’ll have to scale out.
Cheers,
I am just curious. Do you mean saturate nic on the Gatling host? The computer running Gatling?
And, how do I check the GC rate (of Gatling?) and what is too much?
Just interrested if I get the same behavior as this post describes.
Cheers
I used nicstat utility to monitor the behaviour of my NIC:
Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat
12:31:23 eth1 11890.4 396.2 8536.7 0.00 1426.3 0.00 100 0.00
It seems that it isn’t saturated while being 100% utilized. I also used VisualVM to monitor GC activity and it constantly stayed under 1% so I suppose that is not the issue. What I would like to know is what is considered “ok” incoming traffic in case of simulation with 100 sessions, average 40 requests per second and “check”-s in each request. In my case it is about 11.6 mb/s incoming traffic. Does gatling really generate that amount of traffic, or should I continue investigating.
Thanks for your support.
It seems that it isn't saturated while being 100% utilized. I also used
VisualVM to monitor GC activity and it constantly stayed under 1% so I
suppose that is not the issue. What I would like to know is what is
considered "ok" incoming traffic in case of simulation with 100 sessions,
average 40 requests per second and "check"-s in each request. In my case it
is about 11.6 mb/s incoming traffic. Does gatling really generate that
amount of traffic, or should I continue investigating.
Thanks for your support.
Gatling just downloads what it's told to, ie the responses for the requests
you ask it to send.
11.6 mb/s with 40 rps means an average 290kb per request, which is (sadly)
quite standard for web pages nowadays, but unusual for a REST API.
Only you can tell.