Inversely the opposite reaction is achieved by lowering ThreadsPerChild. Fewer threads per child require more children to run an equal amount of MaxRequestWorkers. Since children are full copies of Apache, this increases Apache’s overall memory footprint but reduces the impact when recycling children. Fewer threads mean fewer potential “stuck” threads during the recycle procedure, keeping the higher capacity of requests available overall children. Having fewer threads per child provides increased shared memory isolation. For instance, dropping ThreadsPerChild to 1 gives the same request isolation of MPM Prefork but also inherits its massive performance tax as well, requiring one child per one request.
When setting ThreadsPerChild always consider the server environment and hardware:
- A memory-heavy shared server hosting numerous independent accounts might opt for a lower ThreadsPerChild, reducing the potential impact of one user affecting another.
- A dedicated Apache server in a high-capacity load balanced configuration can choose to increase ThreadsPerChild significantly for a better overall performance of each thread.
ThreadLimit
Used to set the maximum value of ThreadsPerChild. This directive is a hard ceiling for ThreadsPerChild. It helps protect against typographical errors with the ThreadsPerChild directive which could quickly spin a server out of control if too many threads are allowed due to an input error. This setting need to be adjusted in some high-end servers when the system needs more than the default of 64 threads per child.
MaxRequestWorkers / MaxClients
The directive sets the limit for active worker threads across all running children and acts as a soft ceiling with ServerLimit taking control as the hard limit. When the number of total running threads has reached or exceeded MaxRequestWorkers, Apache no longer spawns new children.
Determining the MaxRequestWorkers is a critical part of server optimization. An optimal setting is based on several changing variables. This means its configuration needs to be reevaluated and tailored periodically over time, changed by watching traffic habits and system resource usage. The Apache status Scoreboard is an effective tool for analysis of Apache performance.
It is typical of Worker based MPM systems to run an isolated third-party PHP handler like Mod_fcgid, PHP-FPM, and mod_lsapi. These modules are responsible for processing PHP code outside of Apache and frees up Apache to handle all other non-PHP requests such as HTML, TEXT, CSS, Images, etc… These requests are far less taxing on server resources which allows Apache to handle larger volumes of requests, such as those beyond 400 MaxRequestWorkers.
Beri Komentar