Hi,
I wondered if it was possible to print to stdout or log to the file system, some real-time metrics including current request rate, percentage of errors and average response time during load-test execution and at regular and readable intervals?
Many Thanks
Aidy
Does what’s already printed in the console suffice?
Hi Stéphane
What I currently receive to stdout is the request and response headers, any debug information and a summary table of requests.
This is very difficult to follow when the tests are running. I wondered if we could just have the summary report produced in intervals of x number of seconds (without any other logging info)?
Aidy
You have such detailed information because you lowered logging level to debug, and have logging go to the console.
Reset logging level to error as it was originally, or append logs to a file instead of the console (see logback appenders), and you’d only have in the console the regular periodic summary.
Actually, I second the request. I would love to have “average throughput” and “current throughput” added to the summary statistics table. Same thing with error rates, and maybe even response times. This would come in handy for when I do a slow ramp up so I can calculate the maximum throughput the system can handle. Then I wouldn’t have to wait for the simulation to finish, I could stop the simulation once I have identified it.
It’s also good for the curious, or for giving demos to stakeholders. “Watch, this is how fast our server is responding right now!” 
=> 2.1 or something, when we’ll refactor the stats engine.
agree with all, unix philosophy may be worth a try - pipe the data to another tool.
something simple can be built on the graphite output quickly (assuming you’re on linux or cygwin):
or possibly the file output, or install a graphite compatible timeseries database/charting tool.
configure gatling to enable graphite output
run in another terminal:
nc -l 2003|awk -f a.awk
sample output with a server that varies from100ms to 2ms to 1000ms with inject(rampUsersPerSec(1) to (200) during(60 seocnds).
$ nc -l 2003|awk -f a.awk
--------- stats … timestamp RPS error_percent 95percentile_response_time active_users
1412087306 0
1412087307 3 0 102.000000 0
1412087308 5 0 103.000000 1
1412087309 9 0 103.000000 1
1412087310 12 0 102.000000 2
1412087311 16 0 102.000000 2
1412087312 19 0 102.000000 2
…
1412087335 95 0 102.000000 9
1412087336 98 0 102.000000 10
1412087337 101 0 102.000000 10
1412087338 105 0 102.000000 10
1412087339 119 0 101.000000 0
1412087340 112 0 2.000000 0
1412087341 115 0 2.000000 0
1412087342 119 0 2.000000 0
1412087343 120 0 2.000000 0
…
1412087352 152 0 2.000000 0
1412087353 153 0 2.000000 0
1412087354 159 0 2.000000 0
1412087355 19 0 2.000000 142
1412087356 76 0 1355.000000 231
1412087357 152 80 1797.000000 247
1412087358 132 26 2219.000000 287
1412087359 147 42 2337.000000 313
1412087360 95 4 2381.000000 396
1412087361 87 2 2411.000000 491
…
1412087370 93 0 2533.000000 704
1412087371 118 16 2044.000000 586
1412087372 112 0 1792.000000 474
1412087373 107 0 1945.000000 367
1412087374 105 0 1594.000000 262
1412087375 53 0 1005.000000 209
1412087376 6 0 1001.000000 203
1412087377 100 16 1006.000000 103
1412087378 49 0 1204.000000 54
a.awk:
BEGIN{print “--------- stats … timestamp RPS error_percent 95percentile_response_time active_users -----”;
curr=0
}
{
if($NF != curr) {
print $NF" “n” “epct” “ptile” "u;
}
curr=$NF
}
/allRequests.all.count/{n=$2}
/allRequests.ko.count/{e=$2; if(n==0){epct=0}else{epct=int(e/n*100)}}
/allRequests.ok.percentiles95/{ptile=$2}
/users.allUsers.active/{u=$2}
Hi Alex
Alex wrote:
nc -l 2003
Why are you specifying port 2003 to listen to?
Aidy
Because that’s the default port that graphite protocol servers listen on. It can be changed to any other in the gatling conf
Thanks
Alex
Hi Alex,
That certainly works and so does the awk processing.
Aidy