options/rgw: raise default rgw_max_listing_results=5000

allow clients to request more than the default 1000 keys per request

bucket listing of large buckets (with many shards) can be more efficient
with larger batches. raising max-keys also improves the balls-into-bins
algorithm which we artificially cap at a minimum of 8 keys per shard

with the default max-keys=1000, we reach this min=8 at around 350
shards. above that shard count, we're always requesting more than the
optimal number of entries per shard, so wasting i/o and bandwidth

as we raise the max-keys, we push this minimum to higher shard
counts:

| max-keys | shard count |
|----------|-------------|
|     1000 |         350 |
|     2000 |         720 |
|     3000 |        1100 |
|     4000 |        1500 |
|     5000 |        1900 |

this table was calculated with the formula (using various values of max-keys):

> solve 8 = 1 + (1000/x + sqrt(2 * 1000 * log10(1000) / x))

ex. https://www.wolframalpha.com/input?i=solve+8+%3D+1+%2B+%281000%2Fx+%2B+sqrt%282+*+1000+*+log10%281000%29+%2F+x%29%29

raising max-keys does increase the total memory usage of each bucket
listing request, which gets into megabytes (tens to hundreds?). so i
chose 5000 as a cutoff that covers most of the range up to our current
rgw_max_dynamic_shards=1999

Signed-off-by: Casey Bodley <[email protected]>

Author: cbodley

src/common/options/rgw.yaml.in

@@ -3432,7 +3432,7 @@ options:
   long_desc: This caps the maximum permitted value for listing-like operations in
     RGW S3. Affects ListObjects(max-keys), ListObjectsVersions(max-keys),
     ListMultipartUploads(max-uploads), ListParts(max-parts)
-  default: 1000
+  default: 5000
   services:
   - rgw
   - rgw