MaxRequestWorkers sets the limit on the number of simultaneous requests that will be served and any connection which attempts over this limit will be queued.
It's called "prefork" because Apache httpd always tries to maintain several spare idle server processes, which stand ready to serve incoming requests so that clients don't need to wait for new processes to be forked before their requests served.
RamenSandwich
How is the value of MaxRequestWorkers determined? Is it left to the user of Apache's web server determine the optimal number empirically?
shhhh
What about the situation where all the workers are servicing long requests?
rootB
@RamenSandwich, I found this on the apache documentation:
"In general, Apache httpd is very self-regulating, so most sites do not need to adjust these directives from their default values. Sites which need to serve more than 256 simultaneous requests may need to increase MaxRequestWorkers, while sites with limited memory may need to decrease MaxRequestWorkers to keep the server from thrashing (swapping memory to disk and back)." And this site provides insights about how to tune the parameters: https://httpd.apache.org/docs/2.4/misc/perf-tuning.html
The basic idea is to keep MaxRequestWorkers large enough for handling more requests, and small enough to have enough memory for each workers.
paracon
@shhhh I think the same reasoning holds there as well. The long running requests also require certain memory to carry their execution, and adding more workers will lead to thrashing.
To reduce the starvation of newer, and possibly smaller requests, maybe we could reserve a separate queue that is meant to service smaller jobs, this ensures good responsiveness. On the other hand, the scheduling logic will involve more complexity, and more importantly some idea about the kinds of workload that your server might experience.
MaxRequestWorkers sets the limit on the number of simultaneous requests that will be served and any connection which attempts over this limit will be queued.
It's called "prefork" because Apache httpd always tries to maintain several spare idle server processes, which stand ready to serve incoming requests so that clients don't need to wait for new processes to be forked before their requests served.
How is the value of MaxRequestWorkers determined? Is it left to the user of Apache's web server determine the optimal number empirically?
What about the situation where all the workers are servicing long requests?
@RamenSandwich, I found this on the apache documentation: "In general, Apache httpd is very self-regulating, so most sites do not need to adjust these directives from their default values. Sites which need to serve more than 256 simultaneous requests may need to increase MaxRequestWorkers, while sites with limited memory may need to decrease MaxRequestWorkers to keep the server from thrashing (swapping memory to disk and back)." And this site provides insights about how to tune the parameters: https://httpd.apache.org/docs/2.4/misc/perf-tuning.html
The basic idea is to keep MaxRequestWorkers large enough for handling more requests, and small enough to have enough memory for each workers.
@shhhh I think the same reasoning holds there as well. The long running requests also require certain memory to carry their execution, and adding more workers will lead to thrashing.
To reduce the starvation of newer, and possibly smaller requests, maybe we could reserve a separate queue that is meant to service smaller jobs, this ensures good responsiveness. On the other hand, the scheduling logic will involve more complexity, and more importantly some idea about the kinds of workload that your server might experience.