Requests could be either POST or GET requests.

For both types of requests, there could be parameters.

For POST requests, also refer to issue #14

We need to provide users with the ability to post JSON. Thay could simulate access to Web Services and/or Ajax calls etc.

This method will save repetition of key when writing something like this :

• post("http://myurl") withQueryParam("login", FromContext("login"))

it could become :

• post("http://myurl") withQueryParamFromContext("login")

or, with CoC :

• post("http://myurl") withQueryParam "login"

The engine could print to the log file or to the console the minimum time that the simulation would take for a scenario

This issue is related to issue #11

It concerns the active session graph at a global level

With a long scenario executing, there will also be a lot of different times showed on the X axis of the graphs.

When there are too much of these, they overlap and it is impossible to read the values.

We need a way to provide context data from external feeds, like a file containing users and passwords.

This issue is related to issue #11

It concerns the requests graph at a global level

As we only log requests, times are discrete. The problem is that on the graph, the time axis is not normalized, therefore, all values are equally distributed even if the intervals between them are not the same.

When we call pause in the scenario, we should be able to specify either:

• a value in seconds => pause(3) will make a pause of 3 seconds
• a value followed by its TimeUnit => pause (3000, TimeUnit.SECONDS) will do the same as above

We need to produce charts. Probably use http://www.highcharts.com/demo/line-ajax

1. At first, we can have static HTML pages generated from the raw data and accessing stats files.
2. Once we can log and compute stats into a database, we'll need a webapp (maybe use an embedded jetty or tomcat)

Required pages :

global :
*) number of active sessions (total and per scenario) timed chart
*) number of requests per second (success and failures) timed chart --> count requests in 1 sec windows

per request name :
*) min, max, medium, standard deviation, 90% range
*) dispersion chart

currently Gatling offers the possibility to store values in the context to pass them to next requests. It lacks DSL to get information from this same context.

I added the possibility to add a parameter to a POST request, I thought it was the equivalent of a form parameter, I'm not sure...

If the body is static (like file upload), make use of AHC zero copy capability.

If the body is dynamic, make use of a templating engine like freemarker.

Scenarios should be scripts, not compiled code. Make use of scala interpreter.

To fully support web application and webservices that were built RESTful, PUT and DELETE HTTP words have to be implemented as well.

Allow users to send files via POST requests using AHC zero copy capability => available

We want to simulate a form with file upload.

Make failures red and successes green

As stated in issue #11, create an extractor/presenter couple that shows "min, max, medium, standard deviation, 90% range" information for a request in particular and another couple for a dispersion chart.

Lots of things should be configurable: Akka, AHC, stat handlers implementations, database, etc..

Have a look at configgy used by Akka.

For development purpose, JQuery and Highcharts files are accessed via internet.

For users to be able to use Gatling offline, these files need to be in the package.

As well as JSON, we need to provide support for XML requests

• Date du run -- done
• timestamp de l'envoi de la requete -- done
• temps de réponse -- done
• nom de scnério -- done
• nom de la requete -- done
• userId -- done
• OK/KO + message -- new issue #5

Context must be simpler : juste one map to store data.

Therefore, there will be some refactoring to do at some point

http://opensource.adobe.com/wiki/display/blazeds/Java+AMF+Client

Decide what kind of packaging we'd provide : a zip bundle with predefined folders (lib, conf, scenario, etc...), a assembly with all the modules and dependencies, etc...

Verify that the active sessions are still counted like expected. And make each scenario have its own series.

Make the runner so that it can run multiple scenarios with specific delay and ramp.

For now feeders support TSV files.

Add support for :

• CSV see issue #74
• JSON ?
• XML ?
• Database ?

Use templating capabilities of Gatling to use GWT-RPC protocol

When data is extracted from the log file, it should be presented as graphics, but also exported to a TSV/CSV file.

We can precompile templates with a maven plugin.

For now, there is a problem as it uses a Servlet dependant Context. (see comment in pom of gatling-stats)

We need a tool to facilitate scenario building.
One efficient way would be a recorder to be plugged onto a browser.

Either develop a full HTTP proxy or make use of http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html

Make feeder as a queue and store its content in the context when a request asks for it.

When end of scenario happens in the same second as earlier actions, the counting is broken.

We need a module to compute stats from raw data, like nb of transaction per sec.

1. At first, we probably just need a simple implementation that consumes raw files and generate as many files as graphs.

2. In the long term, we'll need a clean implementation that logs and computes stats in a database.