Andrew Donnellan <andrew.donnel...@au1.ibm.com> writes: > On 26/07/18 23:24, Daniel Axtens wrote: >> Andrew Donnellan <andrew.donnel...@au1.ibm.com> writes: >> >>> On 24/07/18 15:10, Andrew Donnellan wrote: >>>> In 41790caf59ad ("REST: Limit max page size") we limited the maximum page >>>> size to the default page size in the settings. >>>> >>>> This turns out to be rather restrictive, as we usually want to keep the >>>> default page size low, but an administrator may want to allow API clients >>>> to fetch more than that per request. >>>> >>>> Add a new setting, MAX_REST_RESULTS_PER_PAGE, to set the maximum page size. >>>> >>>> Closes: #202 ("Separate max API page size and default API page size into >>>> different settings") >>>> Suggested-by: Stewart Smith <stew...@linux.ibm.com> >>>> Suggested-by: Joel Stanley <j...@jms.id.au> >>>> Signed-off-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com> >>> >>> FWIW we now have this applied on patchwork.ozlabs.org and it appears to >>> be working. Would like some more input as to what an appropriate default >>> limit is. >> >> My completely fact-free feeling/opinion is that if it takes more than >> ~1sec to run on Ozlabs, it's probably too high. Apart from that, I'm not >> fussed. > > OzLabs.org is not a fast machine. 1 second round trip time == 100 per > page. 500 per page == ~2.3 seconds round trip. > > A single 500 item load is still under half the time of doing 5 * 100 > item loads...
I bet MySQL would execute the query quicker :) Anyway, that sounds really quite slow and we should look at why on earth it's that slow - is there some kind of horrific hidden join or poor indexing or query plan or something? -- Stewart Smith OPAL Architect, IBM. _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork