Informative load test 1800 users.

Informative load test 1800 users.

by Łukasz Kurowski -
Number of replies: 5

Hi,

cpu: Ryzen 7700 8/16
Ram: 128GB non-ecc
hdd nvme
1Gbps connection
OS: Proxmox.

Dedicated machine:
OS: ubuntu 22.04
panel: hetiacp
1 trial - 12 cores 98GB ram
2nd attempt - 15 cores 98GB ram

Today we ran load and file load tests for 1800 people. 
We conducted 2 types of stress test and file strees test.

Conclusions ram consumption did not exceed 20GB
The usual stress test
For 12 cores - about 90%
For 15 cores - 75%

File stress test:
For 15 cores ~ 40%

Average of ratings: Useful (2)
In reply to Łukasz Kurowski

Informative load test 1800 users.

by Eduardo Kraus -
Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Łukasz!

It's great that you're conducting load tests! This is essential to ensure that your Moodle can support a large number of users without compromising performance. Now, regarding your test, I'd like to help you better understand the results and perhaps adjust a few details.

When running a load test, it's important to keep in mind a few details that can significantly impact performance and the results you obtained. The first point is whether the tests are being done with bots or browsers. This makes all the difference! When tests are done with bots, PHP is loaded without loading all the assets on the page (such as JavaScript, images, CSS, etc.), which greatly reduces the load on the machine. However, when you're testing with a real browser, it has to load everything, and the load on the server can be much higher because the browser is also performing many other processes, such as rendering graphic elements, executing scripts, and much more.

Another important point you should check is whether the browser cache is being used. The cache can greatly help with performance, as it prevents files from being downloaded repeatedly during navigation, thereby reducing the impact on network and server usage.

Oh, and it's always good to think about the frequency of user navigation! If users are accessing long courses with videos and large texts, navigation will be slower because it will take longer to load the pages. This is very different from a short course, which requires more clicks between screens. User behavior can directly affect server performance during the load test.

So, to improve your test even more, I suggest you review these points and see if something can be adjusted to reflect a more realistic usage scenario. This might help you find the perfect balance to support 1800 simultaneous users without overloading your infrastructure!

We're here to help with anything you need, so feel free to share more details or ask any other questions! 😄

Eduardo Kraus
Teacher and Programmer

Average of ratings: Useful (2)
In reply to Łukasz Kurowski

Re: Informative load test 1800 users.

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi

The two graphs site-by-side give an immediate visual comparison of the two cases. For my understanding, I need some further information.

- I assume we compare the two "tall" graphs, right? The shorter on is incomplete in one.

- The average height of the plateau has sunk from about 86% to about 70%. What does it measure exactly? It says CPU Basic stress. Is it something like the load average of any Unix system?
 
- That stress went down as you gave it more CPUs, from 12 to 15. Isn't that logical, assuming the stress is per CPU?
 
- I was intrigued how one could vary the number of CPUs. I saw that the (silicon) CPU is 16 core. So you have a hypervisor running - you are measuring in a VM and restart it after changing the number of CPUs?
 
- So the OS, Ubuntu Linux 22.04 is the host, right? What is the guest OS? The same?
 
- This "load and file load tests for 1800 people" is a benchmark, I believe. Is it documented anywhere?
Average of ratings: -
In reply to Visvanath Ratnaweera

Odp: Re: Informative load test 1800 users.

by Łukasz Kurowski -
"- I assume we compare the two "tall" graphs, right? The shorter on is incomplete in one."
Yes, you right.

"- The average height of the plateau has sunk from about 86% to about 70%. What does it measure exactly? It says CPU Basic stress. Is it something like the load average of any Unix system?"
Yes, you right.


"- That stress went down as you gave it more CPUs, from 12 to 15. Isn't that logical, assuming the stress is per CPU?"
Yes, you right.


"- I was intrigued how one could vary the number of CPUs. I saw that the (silicon) CPU is 16 core. So you have a hypervisor running - you are measuring in a VM and restart it after changing the number of CPUs?"
Yes, you right.


"- So the OS, Ubuntu Linux 22.04 is the host, right? What is the guest OS? The same?"
Host OS is proxmox debian.
Virtuals are Ubuntu 22.04

"- This "load and file load tests for 1800 people" is a benchmark, I believe. Is it documented anywhere?"

This is a screenshot of the documentation we prepared for the client. I could share the graph but not the rest of the documentation.

Completing the high graph is more of a DDOS attack on the site, the smaller ones are 1800 people loading the page into the browser.
Average of ratings: -
In reply to Łukasz Kurowski

Re: Odp: Re: Informative load test 1800 users.

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
>> - This "load and file load tests for 1800 people" is a benchmark, I believe. Is it documented anywhere?
>
> This is a screenshot of the documentation we prepared for the client. I could share the graph but not the rest of the documentation.

Sorry, if I sounded nosy. The resulting graphs are so clear, I was trying to understand what they test.

> Completing the high graph is more of a DDOS attack on the site,
 
DDOS at which "door"? HTTP(S)? If so, how deep the requests go? Do they go in to Moodle code or do they stop at web server level? If Moodle code, what kind of transactions? If web server level, what do the scripts at receiving end really do? You can take Moodle Bench as an example, where certain tests are just the "server" like CPU or I/O and other tests are "Moodle" in the sense ./admin/index.html always.
 
BTW, DOS or DDOS? I mean, did you have (large) number of clients hitting the server or always one client? If one client, you can't call it a distributed DOS attack.
 
> the smaller ones are 1800 people loading the page into the browser.
 
The same question: Are they Moodle users? What pages do they load?
Average of ratings: -
In reply to Łukasz Kurowski

Re: Informative load test 1800 users.

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I'm a bit of a load testing sceptic. What you have demonstrated is how Moodle performs when load tested. This is not necessarily (I would argue, not at all) how it behaves under real use with human users.

I have had some real experience of this over the years. We have had some actual performance bottlenecks at times but we have *never* been able to predict them or recreate them using load testing.

None of this means that you shouldn't do load testing. Just that you have to be cautious what conclusions you reach.
Average of ratings: Useful (1)