Hey
we need to find a way to automate one of the scripts, as in we’ll use jenkins to start the script, run the simulation and then we want to see the result in the console.
so for e.g. currently we run the test, we get the result generated into a html page and so on and thats all nice and cute but at the same time we’d like to get some output in console, so when gatling runs the test and exports the result id like it to echo something along the lines of “OK 9999 KO 948 Mean 800ms”
is this possible?
i’ve browsed through the documentation but i can’t seem to find a way to do it 
thanks.
Hey,
how about using the gatling-jenkins plugin?
https://wiki.jenkins-ci.org/display/JENKINS/Gatling+Plugin
This will give you feedback on OK/KO and meantimes.
Although I am note sure to understand what you mean by “console”…
Laurent
we’ve tried that it won’t work they way we need it, console as in linux/centos/unix console, when you run the test you get the final bit echo’ed “results generated to file in blabha seconds”
what we want it to say is “KO’s 999 OK’s 9999 Mean 939” for all the requests combined.
so instead of us clicking the url and viewing the html page we would get the final output in console, so when you open jenkins job, run it at the end you’d be able to see the stability of that particular script
What gatling bersion are you using? G2 gives you stuff like this
Simulation finished.
Generating reports…
Parsing log file(s)…
Parsing log file(s) done
thats perfect thanks, on other topic… any way to get it to show URL of the request instead of saying “request 01” “request 02” etc?
Not automatically, you’d have to change the name of your requests in your simulation.
Beware that using URLs for request names blows off reports layout.
this is what we’ve been doing manually, well with a script we wrote but m3 seems to have a different layout and script actually breaks the simulation code.
and replacing 400+ requests manually is not an option, would be nice to have it as a feature
Yeah, we would use this too. I was thinking that maybe somehow you could allow users to register a function that would be called for generating request names. So, logic would be:
- If the user has registered the callback function, then gatling calls it and passes the full URL of the original request. The function returns a String, and gatling uses this as the request name/id.
- If the user hasn’t registered the callback function, then gatling falls back to the auto-generated request name.
I’m not sure how/where you’d register the function, though. For my use case it’d be easy, because we have our own thin wrapper class around the gatling driver, so I could register it in code. For users using the out-of-the-box gatling launcher, it’d be trickier.
I was just thinking of a “useUriForRequestName” param on HttpProtocol that would generate something like “METHOD URI”.
Do you really need to be able to register your own custom function?
Also beware that using such long names will blow reports layout, so PR welcome there…
2013/7/10 Chris Price <chris@puppetlabs.com>
im cool with layout, but we need to see which url is failing, in our case a lot of times it will be images that are slow and we need to optimize that particular server to make it faster, but searching through a recorded script to find the actual culprit is just too much of a hassle in this case.
If I were able to register a custom function, I could parse the URL and return a meaningful (but short) string that wouldn’t blow out the UI.
The implementation of this function would be identical for 99% of the sims that we’d ever generate from the Recorder, so I’d only have to write it once and then never have to worry about manually editing the recorder output again. I could also generate much more useful request names than what the full URI would provide. (In fact, the full URI wouldn’t really even work in our case–I really need to be able to regex it.)
For now, we’re not generating all that many new sims, and ours generally only have 15 or so requests in them, so we can survive editing them by hand. So this isn’t a blocker for us, just a “wish list” item.
Eventually I am really excited about the idea of moving to automating the Recorder sessions. If/when we get to that point, we’ll probably be forced to do something like what Edd described, where we do text processing on the scala file after the recorder generates it. That approach scares me, for exactly the reasons he mentioned
If you were on board with the idea of registering a custom function and could think of a reasonable API to expose that, that’s something that I’d gladly hack on and submit a PR for some weekend if I got a chance
Well, we could simply register a function on HttpProtocol, and maybe provide some built-ins such as the simple one I proposed.
What would the signature be?
(Session, URI) => String?
I think that’d cover my use case. That would be excellent!
not in our case tho, the best thing would be to have a choice in recorder of course, where we could choose what we want to call our requests before the recording starts?
also, m3 has that awesome output at the end… yet a lot has changed and for some reason we can’t get it to work properly…
so e.g.
val chain_0 = exec(http(“request_1”)
.get(“”“/testrequest.js”“”)
changed to
val chain_0 = exec(http(“”“testrequest.js”“”)
.get(“”“testrequest.js”“”)
breaks gatling, we get this;
Exception in thread “main” java.lang.UnsupportedOperationException: There were no requests sent during the simulation, reports won’t be generated
so for some reason it won’t execute that request, any ideas? ^^ this is what the sed script we wrote does, picks the url from “get” and places it in “exec”
any ideas how to work around this? or get the console output from m* to 1.5.2 ? 
thanks.
Ed
Could I see your real file? I don’t think the problem is where you think it is.
i’d love to show the file but it contains some internal urls that we can’t expose i found the problem, it was on my end… i’ve removed the chain1/2/3/4/5 etc because they were not in use, and missed out on 2 which was in use. Added that back and was able to run the simulation, for now we’re sorted but really the url of the actual request instead of “request1/2/3/4” would be a really GREAT addition IMO.
thanks for the help tho, and hopefully you’ll consider adding that feature sooner or later
I was suspecting this kind of problem on your side
“not in our case tho, the best thing would be to have a choice in recorder of course, where we could choose what we want to call our requests before the recording starts?”
Your approach is a bit too simplistic. For example, what if you have GET and POST requests for the same url?
We’ll come up with a solution generic enough so that it would cover all/most use cases, and built-ins that would provide simple solutions for non scala devs.