lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Limiting the number of queries/updates to Solr
Date Thu, 03 Aug 2017 03:33:43 GMT
On 8/2/2017 8:41 PM, S G wrote:
> Problem is that peak load estimates are just estimates.
> It would be nice to enforce them from Solr side such that if a rate higher than that
is seen at any core, the core will automatically begin to reject the requests.
> Such a feature would contribute to cluster stability while making sure the customer gets
an exception to remind them of a slower rate.

Solr doesn't have anything like this.  This is primarily because there
is no network server code in Solr.  The networking is provided by the
servlet container.  The container in modern Solr versions is nearly
guaranteed to be Jetty.  As long as I have been using Solr, it has
shipped with a Jetty container.

I have no idea whether Jetty is capable of the kind of rate limiting
you're after.  If it is, it would be up to you to figure out the

You could always put a proxy server like haproxy in front of Solr.  I'm
pretty sure that haproxy is capable rejecting connections when the
request rate gets too high.  Other proxy servers (nginx, apache, F5
BigIP, solutions from Microsoft, Cisco, etc) are probably also capable
of this.

IMHO, intentionally causing connections to fail when a limit is exceeded
would not be a very good idea.  When the rate gets too high, the first
thing that happens is all the requests slow down.  The slowdown could be
dramatic.  As the rate continues to increase, some of the requests
probably would begin to fail.

What you're proposing would be guaranteed to cause requests to fail. 
Failing requests are even more likely than slow requests to result in
users finding a new source for whatever service they are getting from
your organization.

Your customer teams might not be able to control the request rate, as it
would probably be related to the number of users who connect to their
services.  It seems like a better option to inform a team that they have
exceeded their request estimates and that they will need to come up with
additional budget so more hardware can be deployed.  If that doesn't
happen, then their service may suffer, and it will not be your fault.

The RateLimiter class in Lucene that you mentioned is designed to limit
the I/O rate of disk or network data transfers, not a request rate.  One
of the most visible uses of this capability in Solr is the ability to
limit the transfer rate of the old-style index replication.  It is also
used in Lucene to slow down the disk I/O usage of segment merging.

A custom Solr component could be built that can be added to a request
handler that does what you're proposing.  If you wanted to write such a
component, you could donate it to the project and try to get it included
in Solr.  Even though I believe such a feature is a bad idea, I'm sure
it would be loved by some users.


View raw message