(In reply to comment #0)

If 5000 is too much, should the UI limit be reduced, if not, should the API
limit be raised? If the worry is that the API lends itself more easily to rapid
queries, perhaps some sort of rate limit should be introduced for expensive
queries?

I can't really comment on what's too high and what isn't, someone with more knowledge in the performance field should do that. Something that should be noted is that the 500/5000 limit in the API applies to each query separately, and since there are 34 query types in core (extensions like FlaggedRevs and GlobalBlocking provide even more), even a non-sysop user could get up to 34*500=17,000 results in one request.

matthew.britton wrote:

(In reply to comment #1)

I can't really comment on what's too high and what isn't, someone with more
knowledge in the performance field should do that. Something that should be
noted is that the 500/5000 limit in the API applies to each query separately,
and since there are 34 query types in core (extensions like FlaggedRevs and
GlobalBlocking provide even more), even a non-sysop user could get up to
34*500=17,000 results in one request.

True, I hadn't thought of that. I suppose that's a valid argument for keeping the limit down.

In practise, of course, there aren't any situations where such a request would provide results of any usefulness :)

(In reply to comment #2)

In practise, of course, there aren't any situations where such a request would
provide results of any usefulness :)

While combining all 34 queries is obviously over the top and only really useful for testing or DoS purposes, combinations of 2 or 3 queries are quite common, and even combinations of 10 queries can be useful (all prop= modules combined, for instance).

matthew.britton wrote:

(In reply to comment #3)

While combining all 34 queries is obviously over the top and only really useful
for testing or DoS purposes, combinations of 2 or 3 queries are quite common,
and even combinations of 10 queries can be useful (all prop= modules combined,
for instance).

Yes, I've used a few such queries myself. Perhaps a 'maximum number of queries in one request' limit if DoS is a potential problem?

(In reply to comment #4)

Yes, I've used a few such queries myself. Perhaps a 'maximum number of queries
in one request' limit if DoS is a potential problem?

Maybe, although I'm kind of leery of breaking backwards compatibility. I'll do this only if DoS is a real concern voiced by a developer with authority on the subject.

matthew.britton wrote:

Maybe, although I'm kind of leery of breaking backwards compatibility. I'll do
this only if DoS is a real concern voiced by a developer with authority on the
subject.

OK, just thinking of possibilities :)

Movimg from hardcoded limits to variables (T187752) is arguably one first step to eventually make limits more consistent if desired (or at least to allow sysadmins to make them consistent in their installations without hacks).