Question

Big decrease in perfomance with parallel webservice calls

1

We are performing loadtests on webservices published from a Mx app. We notice a big decrease in performance when using parallel threads. The more threads the longer it takes We also see a big variance in the min and max execution times There are 15 webservices in our testsuite. They are all called using the same webservice user When using 1 thread the average executiontime (sec) is 6/10/7 (min/max/avg) seconds for all services When using 2 thread the average executiontime (sec) is 9/13/10(min/max/avg) seconds for all services When using 5 threads the average executiontime (sec) is 15/34/23(min/max/avg) seconds for all services When using 10 threads the average executiontime (sec) is 30/70/45(min/max/avg) seconds for all services (see screenshot) Can anyone tell me what can be the cause of the decrease in performance and the big variance in execution times. And maybe how we can solve this issue.

asked 2017-01-24

René Smit

4 answers

Paul Ketelaars - Deprecated · Answer 1 · 2017-01-24

We've been playing with the ProcessQueue aswell as a means to increase performance of our application. You can't just select more threads and expect the process to run faster though. Doing so may (and will) cause the opposite effect; slowing down your application, and thus increasing the time it'll take for an action to complete (as you see in your test results).

There's no magic number, that'll solve all performance issues I'm afraid. It's a matter of testing different settings, threads and affinity of the ProcessQueue and optimizing the microflows run within the queue.

That's a short answer based on my experiences, maybe someone has a better explanation though

Hope this helps a bit!

Joël van de Graaf · Answer 2 · 2017-01-24

Hey René. An important source in this question are the graphs of the Mendix cloud environment. How is the app performance based on the monitoring.

In performance testing of our own project, we've found an interesting latency in the execution of the webservices. The password check was very slow. Mendix is standard using BCrypt as password hashing mechanism, only it's designed to have slow factor in the creating the hash. We had better result when using SSHA as password mechanism. You should test SSHA, don't forget to reset the passwords.

https://en.wikipedia.org/wiki/Bcrypt
http://stackoverflow.com/questions/15763086/bcrypt-for-password-hashing-because-it-is-slow

Lucas Meertens · Answer 3 · 2017-01-24

Our experience with web services shows that the web service user logging in has the greatest performance impact. Especially if the setting "keep track of last login" is also enabled.

To avoid this, turn off authentication on the published WS settings. Depending on the case, some other security mechanism may be needed. Also you will not be able to access the WS user as $currentUser.

Russell Martin · Answer 4 · 2017-01-24

What we have found is that using the processQueue has been beneficial but has needed some tweaking. We also found one of our major performance issues was tied around user info and there being locks on the entity due to too many actions trying to access it. This then holds up everything else trying to access it since we are waiting for it to free up. Also we implemented some settings to help cleanup our connections and pools that arent in use. This document here should help explain what settings you could put in the service console to help clean up items.

There is no perfect config. You will have to adjust for your onsite setup and environment. We have onsite setup as well and experienced the same issues. Once you get the proper settings you will notice a big increase. Hope this helps!

https://github.com/mendix/m2ee-tools/blob/master/examples/full-documented-m2ee.yaml