“A process” is, in fact, not equivalent to “a client.”
Most HTTP requests are extremely brief, and, as you well know, “once they've been serviced, they’re gone.” The only thing that ties one request to another are ephemeral things like cookies.
My gut-feeling on this matter is that 150 processes is far too many, because it can very quickly become the case that all of those processes are just fighting among themselves. “There are only 1,000 milliseconds per second; no more, no less.” You can actually do the math here. “If 150 active processes each received a quantum of 2 milliseconds apiece, how many milliseconds of CPU time would they receive each second, and how long would it be (best case) between each opportunity to execute?”
Always remember that adding processes further subdivides, not multiplies, the amount of wall-clock time that everyone receives.
| |
MaxClients is the number of simultaneous clients that a server can process. If you are using the prefork MPM there is one process to one client, and for the worker MPM, there is one thread to one client.
While the request itself might be brief, you still have to consider keep alive requests where one clent can tie up a process for more than one request. You also have to remember that not all users have 100mbps connections to the Internet, so if it takes a user 20 seconds to download an image, one of your MaxClients is tied-up until the user finishes.
Whether 150 process is too many depends on what you are doing and what your hardware is like, but even a moderately priced server gets you 16 cpu threads --so those 150 processes end up being around 10/cpu thread.
| [reply] |
Please say me is one process equals to one client.
No, please read the documentation for MaxClients | [reply] |