566343 - configuration API should be cached by the REST API server

Status: RESOLVED FIXED

(Webtools Graveyard :: BzAPI, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

Bug 553246 was about the configuration API being slow; it sounds like some optimization occurred, but it would appear the cost is still quite high.  (Unless BMO has not yet upgraded/seen the benefits?)

I just did a 24 second configuration fetch on /latest/, and then did another fetch a few seconds later and that still took 16 seconds.  This was with flag fetching, since I primarily want the flags... with flags=0 it took 12 seconds (warm query).

It seems like the query is expensive enough and unchanging enough that the REST API should be caching the value(s).  In fact, given that the hit is so bad, perhaps the common cases should just be refreshed by a cron job so the first person to make the request after the expiration point doesn't get a kick in the pants.

Comment 1

[Gervase Markham [:gerv]]

Indeed. b.m.o. has not yet upgraded - bug 558044.

I don't really want to add caching to the BzAPI for a short period. Can't you cache it client-side? :-)

Gerv

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

How short is the latency with the patch?  My concern is that it's bad UX if the first time every client goes to use the UI they have to wait 10 seconds, ignoring the potential load on BMO.

Comment 3

[Gervase Markham [:gerv]]

My understanding is that it's down to a second or two. But if we upgrade and it's not, then I'll add caching :-)

Gerv

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

A second or two is better, but that's still a really long duration for something that's really easy to cache/pre-cache.  Presumably the query generates a lot of load on bugzilla/the database server and that's why it takes so long?  Wouldn't it be friendlier to not issue wasteful queries?  I'd rather 'spend' that second of server processing time on something more useful to the client...

Comment 5

[Gervase Markham [:gerv]]

OK, the next release of BzAPI will allow you to pass "cached_ok=1" on the configuration call. BzAPI caches the output every time someone calls /configuration (or the noflags variant) and will pass it back to you if you say that it's OK to send cached data. The JSON hash will have a last_updated value which is a unix time_t defining when the data was refreshed. It's your responsibility to see if that's recent enough and, if not, call the call again without "cached_ok=1".

This facility may go away if the call gets fast enough; in particular, don't depend on getting a last_updated value back if you request with cached_ok=1. For a start, the cache might be empty.

Gerv