805109 - Cache BzAPI GET results for 5 minutes to reduce impact of excessive polling

Status: RESOLVED WONTFIX

(Webtools Graveyard :: BzAPI, defect)

Description

[Ed Morley [:emorley]]

In http://globau.wordpress.com/2012/10/09/bugzilla-mozilla-org-integration-best-practices/ glob requests that people do not poll the various APIs more frequently than every 5 minutes.

However:
(a) Some people still are polling more frequently than this.
(b) This doesn't help with client-side bzapi calls used by many of the release/basecamp type tracking dashboards, that perform in the order of 200 bzapi calls from each client on every page load. These dashboards are often opened up by multiple people just before meetings, so would benefit greatly from short-term caching.

After speaking with glob, my proposal:
For each BzAPI GET, cache the returned json & if an identical BzAPI request is made within 5 minutes, then return that cached result rather than polling b.m.o again. Periodically clear the cache of all entries older than 5 minutes etc etc...

Comment 1

[Steve Fink [:sfink] [:s:]]

Shouldn't this be an IT bug? Putting a caching proxy in front of either the bzapi server or the bugzilla server (are those GETs, though? that might be harder) would make a lot more sense that complicating the bzapi code with caching.

Isn't this supposed to be one of the benefits of REST, that it exposes the underlying semantics through HTTP so that the caching can be semantically correct?

Comment 2

[Gervase Markham [:gerv]]

I am not keen to add a cache to BzAPI, for the reasons Steve outlines, and also because it's stable software in maintenance mode, and will hopefully be obsoleted by the REST extension before too long. We could try a caching proxy; I have no experience with such things.

Another option is changes (like my recent change to pass through the Referer, bug 803004) that help us to track down clients which are misbehaving.

Also, if a dashboard is doing 200 queries, surely it can consolidate some of those and do client-side splitting of the results into the various pots that it needs? I find it unlikely that those 200 queries are all unrelated to one another...

Gerv

Comment 3

[Ed Morley [:emorley]]

(In reply to Gervase Markham [:gerv] from comment #2)
> Also, if a dashboard is doing 200 queries, surely it can consolidate some of
> those and do client-side splitting of the results into the various pots that
> it needs? I find it unlikely that those 200 queries are all unrelated to one
> another...

Agreed; but it seems like glob is having to play a game of whac-a-mole at the moment, given that new dashboards are being churned out on a regular basis, to meet whatever is this months' B2G/release management need - many of which not doing the correct thing. Whilst education is also important - it's not going to help us in the short term & for some use-cases it's actually hard for client-side apps to do the right thing with the current API. Caching would also help with the long tail of less widely used dashboards/scripts that might otherwise not be worth the ROI of chasing down & fixing.

If an IT solution would be easier, then happy to morph the bug - it was the general sentiment that I'm more interested in :-)

Comment 4

[Gervase Markham [:gerv]]

Currently, the BzAPI machine is not incredibly powerful and, because it runs multiple instances of BzAPI (different API versions, and different target servers) a reasonable proportion of the machine's memory is used up. I am no expert on these things, but I worry that just adding a naive in-memory cache (hash of query params -> query results) will lead to increased memory consumption, memory exhaustion and a much slower BzAPI for everyone. And something more complex than that starts to get a) out of my comfort zone, and b) into a complexity I don't particularly want to deal with in software which is stable and soon to be obsolete (for BMO purposes).

Therefore, I think the next step is to ask IT whether there are some transparent HTTP caches which might be placed in front of BzAPI to address this issue.

Gerv

Comment 5

[Gervase Markham [:gerv]]

Bug 805763 filed on IT.

Gerv

Comment 6

[Ed Morley [:emorley]]

WFM, thank you for filing that :-)

Comment 7

[Gervase Markham [:gerv]]

BzAPI is very much in maintenance mode and is being superseded by the BzAPI shim on top of the native Bugzilla REST API, and that native API itself. So this bug is not going to be fixed.

Gerv