Load Test M-Files Server with JMeter

Creating load test scenario on a web application might look easy:

1. Record a scenario
2. Replay it

In practice, it is much more complex than that when you want to manage variables elements like usernames, session IDs, and, in case of M-Files, a Vault ID.

Also, JMeter does not manage client-side java script and, if application requires it, you must “emulate” it with some code. Luckily, JMeter can run code with JSR223 Sampler. This requires coding skills to understand what the application does with help of Web Developer Tools provided with your favourite browser.

The first scenario will look like this:

1. Login
2. Search
3. Select first element in the result page
4. Thinking time
5. Logout

Recording

To record, I need a simple scenario with one Thread group with a Recording Controller and a HTTPS Test Script Recorder with a View Results Tree listener. When record is done, you will end up with something like this (a transaction controller for each named steps and as many HTTP request as recorded):

Variables

Search and Find

First job is to find what are the variable parts of these queries. Before that, you must have the following Managers defined:

• HTTP Cookie
• HTTP Authorization
• DNS Cache

The first time we will replay the scenario, it is likely it will fail at a step where a variable part exists. This can be a method to find them.

By looking at each HTTP request parameters, we can also find the variables:

Replace

Next, we must search where is this sid used and where also where to get the value from. So, let’s do a simple search on the recorded value (ie. 36_jWG4pMmwxCVuGAAEk):

Searching in Record Controller will give you all the requests where it is used, but not which one provided the value at first place. Nevertheless, we can still do the string replacement:

Extract

To find which request return the SID to use, the search must be conducted in the View Result Tree:

Next step is to add a Regular Expression Extractor to populate SID variable for later query use:

Finally, we can run the scenario and analyse how it behaves. After this second run, I found another kind of session ID specific to M-Files:

Similarly, as sid, I search and replace that value with a variable name (ie. M-FILES-SID) in recording controller and search where it comes from in View Result Tree. As it provided in the body of a HTTP request in JSON format, I can use JSON Extractor:

During third run of scenario, I discovered that this M-FILES-SID changed just after the login which prevent scenario to complete. Adding a copy of the JSON Extractor where the new M-FILES-SID is returned will do the trick.

Diving in the JavaScript Code

Did you notice the “t” variable in the first screenshot of an HTTP request? I did notice it, but it does not cause any problem to my scenario runs. I also notice that there are many calls to /socket.io URL to the M-Files server. With help of browser Web Developer Tools, I was able to find which part of the code is generating this variable:

So, I did more digging and found what it is used for:

It is a way to avoid browser to use cache when it should not. This technique is called cache busting. It allows to control when a browser should reload the file or, even to avoid any cache at all.

By looking at socket.io code, I was able to find how this “t” variable is generated and replicate in the JMeter scenario to get even closer to browser behaviour. It comes from yeast github repository where I also found the code.

Conclusion

As you have seen, load testing is not a “long quiet river” and require coding skills as well as tenacity. Do you feel scared by that? No problem, we are here to help with our expertise on load testing of web applications.