3 Reasons to combine JMeter and WebDriver in performance testing a webapplication
What is JMeter good at?
The Apache Foundation states the following about JMeter:
The Apache JMeter™ desktop application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
So in other words, it’s a tool you can use to generate functional load on an application or a platform. This also immediately describes what it is good at: generating load. Yes if implemented well you not only generate dumb-load but also hit the functional application layers with the tool. But the basic function of JMeter is aimed at generating load and measuring the (server) response times during this load.
What does JMeter NOT do?
What is WebDriver good at?
SeleniumHQ gives a wonderful description of what Selenium (or nowadays WebDriver) does:
Selenium automates browsers. That’s it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that.
What does WebDriver NOT do?
Well, it is not quite good at generating load. Since WebDriver basically requires a browser (yes, it is possible to run it headless of course) it is very difficult to generate multiple (virtual) users. That would require a bunch of browsers to start up, when talking about 10 users that may seem feasible, however when talking about generating real load (say several 1000’s concurrent users) a bunch of browsers becomes a lot more difficult to arrange.
Why combine them then?
The logical question then indeed is, why would you combine them? Below I have set out 3 clear reasons why combining JMeter and WebDriver scripts can be an excellent idea.
- Impact of server-side load on render-times;
When the load on a server increases, the response times of various parts of a web application may increase as well. These increased response times can have implications on the render time of the web application. For example: a web application heavy with Ajax requests is put under load, the server response times increase, this may result in all Ajax-requests becoming slower, therefore making the website extremely unfriendly to the end-user. When you just run a JMeter script, this will hardly be noticed, and if you do notice it, you cannot express the impact it will have on the user. You can merely speculate about it.
- Impact of server-side load on functional behavior;
Given that the server is experiencing increased load and therefore the business-logic of the application is working hard to handle all requests effectively, it can be safe to say the underlying database may also be stressed and therefore responding slower than expected. Slower response times of both application-logic and database requests can result in buggy behaviour of the application. For example incomplete data returned, or worse, a time-out on data or application-logic. How does the application deal with that? How are these errors reported to the end-user? Will the application still function normally within the browser when certain aspects of the application platform are malfunctioning? The best answer to this is by testing the functionality thoroughly while the application is under load. An easy way to test this repeatedly and consistently is by automating these functional tests, for example using (part of) the automated regression test while the servers are under increased load.
- Advantage of screenshots of fully rendered pages and possible errors with the application under load;
I have listed 3 reasons why combining JMeter and WebDriver can be a good idea. I’d love to hear your suggestions of more reasons to want to combine the two.
In a follow-up post I will go into more detail on ways to achieve an effective combination of JMeter and WebDriver running along side each other, well timed and generating consistent logging and results.
I’ve done this before for a product(Jmeter+Webdriver) successfully. There are many more reasons why one should do this.
For example: You need to know how much time is being spent on rendering the data on the UI. Jmeter provides limited but good support and workarounds to achieve this and much more.
Does it impact on response time when we are executing load test?
Sorry, not been paying attention and simply missed your questions.
Not sure if I am answering your question correctly now, since I don’t fully understand it.
When putting the application under load, you influence the response times, that is part of what you at least are trying to measure.
In order to verify what the response times for your end-user are going to be you want to have a full browser based test including the load in the background.
As long as you don’t do all from within the same box and keep network limitations in scope, the test itself does not impact on response times.
won’t it impact on response time when we are executing load test?
How do you mean, which response time and impact on what exactly?
Not sure I understand your question.