Hello,
Is there a way to log parameters for each request sent? There is no such information in the simulation.log, and it would be useful because when using a feeder, there is no way to know what was sent in the request.
Thanks
Hi Joël,
I think there’s no easy way to do so right now. It may be a new feature, I don’t know what Stéphane thinks about it 
Thanks for your input 
Cheers,
Romain
Hi Joël,
For debugging purpose, you can simply set the logging level to DEBUG in the logback.cong file.
It will log the HTTP requests and response.
Cheers,
Steph
PS : @Romain: get some sleep (but finish migrating the recorder)!
2012/3/5 Romain Sertelon <bluepyth@gmail.com>
logback.xml cong file, I mean
2012/3/5 Stéphane Landelle <slandelle@excilys.com>
Well logging each request is good for debugging, but I would like to be able to analyse slow requests : see if the response time depends on the parameter (in my case, detecting data duplication). So I was wondering if it was possible to extends data logging, and then either extend the report generation to add new charts or use external tools to handle this (when I was working with JMeter, I was using Birt to generate custom reports about my load tests).
Hi Joël,
The problem with logging the requests and the responses is that it deteriorates performance (converting Request and Response objects to Strings and writing them down).
There’s been some thinking about data writing and reading overriding but it’s very experimental. We’ll rewrite the Data and Reports API in a next version.
We could investigate how to have an option for logging request and response data and let you generate your own charts from the simulation.log.
The problem I see is that you want parameters for your use case, someone else will want query parameters and someone else will want a whole json body, and having all this data encoded so that it fits in a CSV might be a problem.
So, basically, I feel like it’s not a simple feature and we need some time to think about it.
Steph
2012/3/6 Joël Vimenet <joel.vimenet@gmail.com>
Maybe what we could do is providing two hooks, one (Request => String) and one (Response => String), that would produce data to be logged.
It would be your responsibility not to induce too much overhead and to analyze the simulation.log.
People, WDYT?
2012/3/6 Stéphane Landelle <slandelle@excilys.com>
It seems a good idea. If I remember well, when I was working with jmeter, it logged a timestamp, an id of request, an id of user, the url, the response status and maybe a few other things, but it was quite lite. Maybe my need is very specific, but the API you propose is simple enough to fit all the needs.
- a timestamp: already available
- an id of request: should be an uuid so it can work in cluster mode (one day, I promise) → TODO
- an id of user: already available
- the url: maybe sufficient for you need, but should be more generic with the (Request → String) hook → TODO
- the response status: need to add a field for protocol specific code, as the Gatling engine should be protocol agnostic → TODO
I’ll fill issues for those, but they probably won’t make it for 1.1 as we’d like to release it mid-march.
Be patient…
Cheers,
Steph
2012/3/6 Joël Vimenet <joel.vimenet@gmail.com>
No problem thanks a lot!
Wondering how does this go? I am very interested in this feature. (I am using 2.0.0-M2 now)
You can probably do most of it with extraInfoExtractor https://github.com/excilys/gatling/wiki/Gatling-2#wiki-http-misc
Otherwise, you can implement your own DataWriter: https://github.com/excilys/gatling/blob/master/gatling-core/src/main/scala/io/gatling/core/result/writer/DataWriter.scala#L54
Cheers,
Stéphane
Sorry, do you have an example on how to use this function: extraInfoExtractor? Looking at an example is still much easier for me.
Thx a lot!
figured out this by checking through the groups:
val httpConf = httpConfig
.baseURL(“http://ft-lb”)
.extraInfoExtractor((status:Status, session:Session, request:Request, response: Response) => {
ListString
})
So in the twiki,it is said extraInfoExtractor(RequestStatus, Session, Request, ExtendedResponse) => List[Any]].
But the actual one should be extraInfoExtractor(Status, Session, Request, Response) => List[Any]].
You’re right, RequestStatus and ExtendedResponse have been renamed in M3. Thanks for repoting.