Hi, For my purposes IP address is an acceptable definition of a user. In any case I would use the commercial subscription if it would help with this problem.
Rate limiting doesn't help because I don't know ahead of time whether a user will make many fast requests, or fewer slow requests - and in fact a user might make a mix of fast and slow requests, so rate limiting wouldn't be effective at limiting the resources being used. Regards, Chris. B.R. Wrote: ------------------------------------------------------- > First, you need to define 'user', which is not a trivial problem. > Unless you use the commercial subscription, it is hard to tie a > connection > to a session. You can use components in fornt of nginx to identify > them > (usually with cookies). > Thus 'user' in nginx FOSS usually means 'IP address'. > > Now, you have the limit_conn > <http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html> > module, as > you noticed, which allows you to limit (as its name suggests) > connections, > and not rate (which is the job of... the limit_req > <http://nginx.org/en/docs/http/ngx_http_limit_req_module.html> > module). > You need to set a key on the zone to the previously told value in > order to > identify a 'user'. Then the limit_conn directive allows you to set the > connections limit. > > To make the limit number vary, you will need to automatically > (periodically) re-generate some included configuration file and reload > nginx configuration, as it is evaluated once before requests are > processed. > You might also use some lua scripting to change it on the fly, I > suppose. > > However, you won't be able to do anything else by rejecting extra > connections with a 503 (or another customisable HTTP code). The client > will > then need to try to connect again following a certain shared protocol > after > some conditions are met (time?). > > === > > Another idea (looks like dirty, but you will decide on that): > If you know what time a specific request needs to complete, you can > try to > play with limit_req to limit connections, using the burst property of > this > directive to stack waiting (but not rejected) connections. > Say you want to limit connections to 5, but accept up to 10 of them, > all > that in 30s, you can use a limit of 5 associated with a rate of 2/m > and a > burst of 5. > > All that requires testing, provided I correctly understood your > specifications. > My 2 cents, > --- > *B. R.* > > On Sun, Feb 8, 2015 at 11:41 PM, ChrisAha <[email protected]> > wrote: > > > I am using nginx as a reverse proxy to a Ruby on Rails application > using > > the > > unicorn server on multiple load-balanced application servers. This > > configuration allows many HTTP requests to be serviced in parallel. > I'll > > call the total number of parallel requests that can be serviced 'P', > which > > is the same as the number of unicorn processes running on the > application > > servers. > > > > I have many users accessing the nginx server and I want to ensure > that no > > single user can consume too much (or all) of the resources. There > are > > existing plugins for this type of thing: limit_conn and limit_req. > The > > problem is that it looks like these plugins are based upon the > request rate > > (i.e. requests per second). This is a less than ideal way to limit > > resources > > because the rate at which requests are made does not equate to the > amount > > of > > load the user is putting on the system. For example, if the requests > being > > made are simple (and quick to service) then it might be OK for a > user to > > make 20 per second. However, if the requests are complex and take a > longer > > time to service then we may not want a user to be able to make more > than 1 > > of these expensive requests per second. So it is impossible to > choose a > > rate > > that allows many quick requests, but few slow ones. > > > > Instead of limiting by rate, it would be better to limit the number > of > > *parallel* requests a user can make. So if the total system can > service P > > parallel requests we would limit any one user to say P/10 requests. > So from > > the perspective of any one user our system appears to have 1/10th of > the > > capacity that it really does. We don't need to limit the capacity to > > P/number_of_users because in practice most users are inactive at any > point > > in time. We just need to ensure that no matter how many requests, > fast or > > slow, that one user floods the system with, they can't consume all > of the > > resources and so impact other users. > > > > Note that I don't want to return a 503 error message to a user who > tries to > > make more than P/10 requests at once. I just want to queue the next > request > > so that it will eventually execute, just more slowly. > > > > I can't find any existing plugin for Nginx that does this. Am I > missing > > something? > > > > I am planning to write a plugin that will allow me to implement > resource > > limits in this way. But I am curious if anyone can see a hole in > this > > logic, > > or an alternative way to achieve the same thing. > > > > Thanks, > > > > Chris. > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?2,256517,256517#msg-256517 > > > > _______________________________________________ > > nginx mailing list > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx > > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx Posted at Nginx Forum: http://forum.nginx.org/read.php?2,256517,256529#msg-256529 _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
