I just came around a tool called Gatling (http://gatling-tool.org/) to create load tests for web applications. I used to use JMeter for a long time, but JMeter has weaknesses that Gatling doesn‘t have.
JMeter uses a synchronous request approach. That means for every request JMeter generates, an internal thread is raised and therefore blocked until a response is being received or a timeout happens. This results in resource blocking on the load injector. The maximum number of threads is limited within a JVM - dependent on the underlying infrastructure - and even if you are able to run a lot of parallel threads this will result in a high CPU and memory utilization. Although performance tweaking and scaling out to distributed testing might help in such a case, it makes testing more complex and error-prone.
This behavior can result in distorted metrics. Think about a typical breakpoint load test. You want to determine, which is the maximum number of requests per second your tested system can serve. This will be limited by JMeter to
max_requests_per_second = (1000 / average_request_time_in milliseconds) * max_jmeter_threads
Even if the system could server more, this is the maximum number JMeter can inject. This is especially important when the tested application has long response cycles, e.g. because of long lasting transactions or long lasting calculations within the requests.
Gatling is a tool built on Scala and Akka which is capable to serve much more parallel requests. It doesn‘t use a „thread per request“ model. Requests are generated using Akka concurrency features. Akka is built on Scala actors, that are internally based on isolated futures which can be created very fast and managed independently in a large number within a system. This makes is easy to create tens of thousands of parallel request on a convenience hardware based load injector.
Like JMeter, Gatling can be configured using scripts, „Scanarios“ in the Gatling terminology. Those are created in a Domain Specific Language that can be build with Scala features. For example a test with a simple clickstream in a web application can be defined as follows:
The script is more or less self-explanatory. It creates a scenario with 2 requests and 2 pauses. Afterwards a load test - a so called simulation - is defined with 4000 parallel users and a time of 180 seconds after which all users are active.
This combination of Scala based DSL and scripting together with the actor based concurrency model and an extremely lightweight CPU and memory footprint makes Gatling to me a first choice for future projects.
JMeter uses a synchronous request approach. That means for every request JMeter generates, an internal thread is raised and therefore blocked until a response is being received or a timeout happens. This results in resource blocking on the load injector. The maximum number of threads is limited within a JVM - dependent on the underlying infrastructure - and even if you are able to run a lot of parallel threads this will result in a high CPU and memory utilization. Although performance tweaking and scaling out to distributed testing might help in such a case, it makes testing more complex and error-prone.
This behavior can result in distorted metrics. Think about a typical breakpoint load test. You want to determine, which is the maximum number of requests per second your tested system can serve. This will be limited by JMeter to
max_requests_per_second = (1000 / average_request_time_in milliseconds) * max_jmeter_threads
Even if the system could server more, this is the maximum number JMeter can inject. This is especially important when the tested application has long response cycles, e.g. because of long lasting transactions or long lasting calculations within the requests.
Gatling is a tool built on Scala and Akka which is capable to serve much more parallel requests. It doesn‘t use a „thread per request“ model. Requests are generated using Akka concurrency features. Akka is built on Scala actors, that are internally based on isolated futures which can be created very fast and managed independently in a large number within a system. This makes is easy to create tens of thousands of parallel request on a convenience hardware based load injector.
Like JMeter, Gatling can be configured using scripts, „Scanarios“ in the Gatling terminology. Those are created in a Domain Specific Language that can be build with Scala features. For example a test with a simple clickstream in a web application can be defined as follows:
val stdSearch = scenario("Standard Search")
.exec( http("Access Google").get("http://www.google.com") )
.pause(2, 3)
.exec( http("Search for 'auconsil'").get("http://google.com/#").queryParam("q","auconsil"))
.pause(2))
setUp(stdSearch.users(4000).ramp(180))
The script is more or less self-explanatory. It creates a scenario with 2 requests and 2 pauses. Afterwards a load test - a so called simulation - is defined with 4000 parallel users and a time of 180 seconds after which all users are active.
This combination of Scala based DSL and scripting together with the actor based concurrency model and an extremely lightweight CPU and memory footprint makes Gatling to me a first choice for future projects.
Kommentare
Kommentar veröffentlichen