It is a tool for carrying out performance tests of the server and database used by our application. Such tests allow us to estimate how many users of our application will be able to use it in comfortable conditions and will allow us to see when we should change to a more efficient server. Such tests also allow us to verify which parts of the code are inefficient and require rewriting.
When we run JMeter for the first time, we have the impression that it is quite a complicated tool, but there is nothing wrong with it. The GUI is very intuitive, and after a few minutes, we can learn the ropes of it, and start using it for its basic functions. We will use BlazeMeter to prepare the tests. It is an extension to the Chrome browser, which saves everything we do in the program and can play it back later. Based on these recordings, we can also export the file that we can add to the JMeter instead of adding everything manually.
The development process was practically finished. The client decided that it was a good time to put the application into use for ordinary users, so we decided to check for the last time how the application will behave with really large numbers of users. We are talking about 20,000 people online. I recorded the registration process and job search using BlazeMeter and exported a JMX file in which all the activities that JMeter needs to run are saved.
The next thing you need to do is to determine how many users you want JMeter to fake. In my case, it was 20,000, so we also need to determine how many of them should perform their tasks per second. I think the 10-50 range will be appropriate in this situation. So we click on "Thread group" and set specify those options:
- Number Of Threads - the number of threads used to send requests,
- Ramp-Up Period - in how many seconds the requests are to be sent,
- Loop Count - how many times a given test is to be repeated,
- Delay Thread creation until needed - without this option checked, JMeter will allocate all memory for all threads immediately. This means that even if the user performs his sample after e.g. 30 minutes, the memory will be reserved for him immediately after running the script,
- Scheduler - we can set what day and time we want to run the test.
Enabling tests is very easy. It only requires clicking on the "PLAY" icon. Now we have to wait. How much? It is hard to say because it depends on how many tests we do, how many users, and what computer we have.
It turned out that the application is inefficient in several places, and it takes too long for the server to respond. We managed to identify places that should be changed or rewritten. Where the code was very slow, we decided to use SQL Views to get the best server response time.