740649 - Cache the product/component list, yet let the server notify when it expires.

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Albert Ting]

This is how I addressed a key performance problem loading a large number of products.  I'm treating it as a separate ticket from bug 733201 as ultimately an AJAX approach may be better.  Still, what I've done is good enough at my site with ~3000 products. So maybe a combination of AJAX and this approach.

With large amounts of semi-stable dynamic data (.ie the large product list), it is best to cache the data and have faster response times for repeat visits. However, caching generally means stagnant data.

To avoid this, I used a "server-side cache expiration notification" technique.  The browser caches web pages based on the full URL with path_info data.  So I embedded a "checksum" in the path_info, which allows the server to tell the browser when to load a new version.  Specifically, I added a User::get_checksum that returns a checksum based on User::get_enterable_products.  

So the show_bug.cgi script has this:

   show_bug.cgi:
       
       ...non-cached content....

       <script type="text/javascript" 
               src="/cached_data.cgi?ck=<% user.get_checksum() %>">
       </script> 

       ...javascript code to render the product list based on cached-data.cgi
   
   cached_data.cgi:

       ...dynamic JSON data containing the product list

With this setup, the browser caches the dynamic content from cached_data.cgi (based on checksum). Each time the product list changes, the checksum changes.  Each time the checksum changes, the browser fetches a newer product list. Otherwise it uses the cached version. Net result, no stale product list.

I took this one step further.  I used the single JSON object, along with YUI menubar plus N-level classification support (bug 291245, comment 9), and added a bunch of hierarchical menus ("new ticket by product", "search ticket by product", "clone ticket by product", "edit product", etc).  There was no extra bandwidth involved and a nominal performance degradation rendering the additional hierarchical menus.  And selecting a product is extremely efficient.

The same approach was used for query.cgi, where I cached the component/version/milestone content. I also deflated/gzipped the JSON object for further bandwidth reduction.

After I pushed this out, bandwidth dropped 2x-3x.  The bandwidth has remained stable even though number of visits have increased, sometimes by 70%.  I'm using 4.0/mod_perl and response times for query.cgi (after caching) is roughly the same as bugzilla.mozilla.org and faster for show_bug.cgi.

Comment 1

[Max Kanat-Alexander]

Yeah, I think that something like this is the right way to go for performance on product stuff. I'd like to see it integrated into our normal webservices flow somehow, though--perhaps setting appropriate Cache headers on GET responses from certain methods.