How to cap server load?

I really want to ensure that my web servers are not overloaded.

Can I do this with nginx?

That is, is there a variable I could test to decide whether nginx should
send the request to the local PHP backend or to forward the request to
other nginx servers in the server farm, based on the load of the PHP
backend? Maybe a variable that contains how many concurrent requests to
nginx are waiting for a response?

You need to test the response time of a sample php script. Mark the
back end as down if it fails the response time threshold a certain
number of times. After you back off, it should recover health if your
algorithm is working. Remember, the database is likely to be the
ultimate performance issue with php performance.

Stefan C.

Good idea of measuring actual response time, but I’m just looking to for
a more crude limit of setting a maximum number of concurrent requests
for the localhost server before requests are “bounced” to another

But, do you know how to do the “response time” limit within NGINX? Or,
do I need to do this test with scripts outside NGINX and have all load
balancers that send requests to this backend do health checks (again
outside NGINX) and edit configuration file and reload NGINX?

If so, I might as well put HAProxy in front of NGINX which can do what I

I was looking for a simple way within NGINX to see how many concurrent
requests there are for the localhost backend.

Just exploring my options…


There are a number of ways; varnish does this with its director back
end definitions, gdnsd also lets you use health checks to manage
server pools, and you have mentioned haproxy. The reason I mentioned
database at the beginning, is that you ultimately have to “protect”
the database with your system, by identifying which requests are
hurting you most frequently, and looking for creative ways to reduce
that pressure on the database. Unless you can provide relief and
backend pool management with a protection system, you can make things
worse with larger webservers and more backends.