Optimal MPM and PHP-FPM set up for many (4000+) concurrent users

Optimal MPM and PHP-FPM set up for many (4000+) concurrent users

by Gregory Jarvis -
Number of replies: 5

Hello!

We are having trouble with our server and many concurrent users. We want to support at least 4000 concurrent users.

Our server has 32 cores and 192GB of RAM, which should be enough. We run MPM_event with PHP-FMP

PHP-FPM config:

pm = static

pm.max_children = 4800

MPM_Event conf:

<IfModule mpm_event_module>

 ServerLimit           100

  StartServers            16

  MinSpareThreads         50

  MaxSpareThreads        300

 ThreadsPerChild        50

ThreadLimit 64

  MaxClients            3000

  MaxRequestsPerChild  0

MaxConnectionsPerChild    8000

</IfModule>


We tried to fine tune this settings but without success. After ~400 (not 4000) concurrent users the website slows down and become unresponsive. Any suggestion on how to improve?

By looking at "top" on average an Apache process and PHP-FPM process are 40MB.

When the website become unresponsive only 30GB out of 192GB of RAM are used. 


What other configuration might slow everything down?

Average of ratings: -
In reply to Gregory Jarvis

Re: Optimal MPM and PHP-FPM set up for many (4000+) concurrent 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
4000 concurrent users is a lot. However, my first question is "how are you measuring concurrent users?"

You've told us very little about your server(s). Is this running *everything* or just the web server? I'd be concerned about that number of concurrent users and I have a cluster of web servers.

What other monitoring are you doing? You should be monitoring all the server parameters you can. If you want a suggestion look at Munin for a simple solution.
Average of ratings: Useful (1)
In reply to Howard Miller

Re: Optimal MPM and PHP-FPM set up for many (4000+) concurrent users

by Gregory Jarvis -
The server is running everything. By 4000 concurrent users I mean currently on the website, so not really 4000 simultaneous requests, but not far from it.

I'm quite new to this stuff so not sure what I'm doing. But so far I've read that the MPM and PHP FPM configs are the one that matter the most, so I'm not monitoring anything aside from "it's crashing/it's working".

What I would like is to maximize the available RAM as much as possible
In reply to Gregory Jarvis

Re: Optimal MPM and PHP-FPM set up for many (4000+) concurrent 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 don't even know if it's Windows, Linux or something else. "not far from" 4000 simultaneous requests is probably a very big ask. 

If you've done nothing then your server is unlikely to be optimised unless you've tuned Apache, the database and so on. They're unlikely to be using available memory in a useful way.

I would certainly install Munin and monitor closely what's going on. There's a whole lot more to this than the FPM settings.
Average of ratings: Useful (1)
In reply to Gregory Jarvis

Re: Optimal MPM and PHP-FPM set up for many (4000+) concurrent users

by Ken Task -
Picture of Particularly helpful Moodlers

With an all in one server it's web service config + DB server config ... a balancing act between them - while allowing the operating system enough to do what it does/must do.

In that light, assuming Linux OS, suggest installing and running MySQL Tuner - which would require perl be installed ...

https://github.com/major/MySQLTuner-perl

'SoS', Ken

Average of ratings: Useful (3)
In reply to Gregory Jarvis

Re: Optimal MPM and PHP-FPM set up for many (4000+) concurrent users

by Tomoya Saito -
Picture of Plugin developers
Construction of an all-in-on server for huge users is very difficult.
We have 6 web servers, and each server has 8 vCPU cores, and 64GB virtual memory.
We have other servers (DB server, cache server, and load balancer).
We spent over a year adjusting over a hundred parameters for our servers.
Our Moodle system can accommodate more than 3000 users, but not 6000 users.

If you employ Linux OS, you must set maximum number of concurrent open files, and maximum number of concurrent open sockets.
Web server (Apache, etc.) connect to users' browsers via sockets.
One connection uses at least one socket.
So, "net.core.somaxconn" kernel parameter must be set to the larger value than maximum concurrent users on your Moodle system (over 4000).
Additionally, web server's processes (or thread) connect to DB server (MySQL, etc.) via sockets (over 4000).
Sure, database server uses sockets (over 4000).
So that, the "net.core.somaxconn" must be larger than 12000.
Moreover, you should set other kernel parameters about backlog, network buffers, and TCP.
In order to improve the communication speed and reduce the packet loss, the network buffers must be set large.
However, large network buffers quickly consume server's memory.

I guess the maximum number of concurrent open files should be set to more than 100 times the maximum number of concurrent users.
So, this parameter may should be set to 400000 or more larger value.
Under this conditions, server's disk must have very high speed an very large IOPS.

By default, maximum connections of database server (MySQL, etc.) is 100-300.
So, you should increase maximum connection parameter of database server.
And, you should adjust other many parameters (global buffers, thread buffers, I/O parameters, etc.).
We have carefully adjusted over 50 parameters.
Increase of these buffers can improve performance of database server.
However, large buffuers consume server's memory.
On the other hand, you also have to reserve memory to store the Moodle database.
Therefore, parameter adjustments should be made carefully.

When the number of concurrent users reaches 4000, required network transmission speed will exceed 1 Gbps.
So, your server must have 10 Gbps network interface.

Finally, I do not recommend using an all-in-one server if the number of simultaneous users exceeds 1000.
The Moodle system has long-term connections with users' browsers and DB server.
As the number of connections increases, behavior of server OS becomes unstable.
Average of ratings: Useful (4)