Merge lp://staging/~sinzui/launchpad/registry-tales-2 into lp://staging/launchpad

Proposed by Curtis Hovey
Status: Merged
Merged at revision: 11077
Proposed branch: lp://staging/~sinzui/launchpad/registry-tales-2
Merge into: lp://staging/launchpad
Diff against target: 97 lines (+22/-9)
4 files modified
lib/lp/registry/browser/tests/milestone-views.txt (+15/-4)
lib/lp/registry/templates/distroseries-needs-packaging.pt (+2/-1)
lib/lp/registry/templates/distroseries-packaging.pt (+2/-1)
lib/lp/registry/templates/milestone-index.pt (+3/-3)
To merge this branch: bzr merge lp://staging/~sinzui/launchpad/registry-tales-2
Reviewer Review Type Date Requested Status
Leonard Richardson (community) Approve
Review via email: mp+28760@code.staging.launchpad.net

Description of the change

This is my branch to adjust the cache rules for registry pages.

    lp:~sinzui/launchpad/registry-tales-2
    Diff size:
    Launchpad bug:
          https://bugs.launchpad.net/bugs/599614
          https://bugs.launchpad.net/bugs/599818
    Test command: ./bin/test -vv \
          -t milestone-views -t packaging-views \
          -t xx-sourcepackage-packaging -t xx-show-distroseries-packaging
    Pre-implementation: no one
    Target release: 10.06

Adjust the cache rules for registry pages
-----------------------------------------

Bug #599614 [bad caching in milestone page]
    "Assigned to you" <- the data is user-specific, pubic, not private

Bug #599818 [distroseries +packaging and +needs-packaging could cache]
    Recent schema changes make data retrieval for +packaging and +needs-
    packaging much faster, but packages are added/removed from +packaging and
    +needs-packaging about 10 times a day. The queries rarely return *new*
    information. A 30 minute public cache will help the pages display quicker.

Rules
-----

Bug #599614 [bad caching in milestone page]
    * Use "private" cache so that the "Assigned to you" information is really
      about you.
    * Add a test for this since it is now understood that the information
      is personalised.

Bug #599818 [distroseries +packaging and +needs-packaging could cache]
    * Add tal:content="cache:public, 30 minute" to +packaging and
      +needs-packaging.

QA
--

Bug #599614 [bad caching in milestone page]
    * As anonymous, visit an old milestone that you know you were assigned
      bug.
    * Verify it states that no bugs or blueprints are assigned to you.
    * Login.
    * Verify the page states the number of bugs or blueprints assigned to you.

Bug #599818 [distroseries +packaging and +needs-packaging could cache]
    * Visit https://edge.launchpad.net/ubuntu/maverick/+needs-packaging
    * Load the page 5 times and verify it does not timeout once it renders
      (staging will probably not timeout because if the schema changes)
    * Visit https://edge.launchpad.net/ubuntu/maverick/+packaging
    * Load the page 5 times and verify it does not timeout once it renders

Lint
----

Linting changed files:
  lib/lp/registry/browser/tests/milestone-views.txt
  lib/lp/registry/templates/distroseries-needs-packaging.pt
  lib/lp/registry/templates/distroseries-packaging.pt
  lib/lp/registry/templates/milestone-index.pt

Test
----

    * lib/lp/registry/browser/tests/milestone-views.txt
      * Revised the test to work with only the content under test.
      * Added a test for the cache rules of the activity portlet.

Implementation
--------------

    * lib/lp/registry/templates/distroseries-needs-packaging.pt
      * Added a 30 minute public cache.
    * lib/lp/registry/templates/distroseries-packaging.pt
      * Added a 30 minute public cache.
    * lib/lp/registry/templates/milestone-index.pt
      * Changed the cache rules from public to private.

To post a comment you must log in.
Revision history for this message
Leonard Richardson (leonardr) :
review: Approve
Revision history for this message
Martin Pool (mbp) wrote :

If I had fixed this I would have kept the overall project counts cached as public, and just made the assigned bugs count private. I don't have a good feel for whether the cost of recalculating them actually makes that worthwhile.

Revision history for this message
Curtis Hovey (sinzui) wrote :

The calculations appear to be very expensive because of the possibilities of private bugs. The loop that creates the info, while heavily cached and optimised to make minimal passes through the list often appears in timeouts. Bug privacy truly sucks. I prefer to cache the whole thing because I would like to go one month without complaints of timeouts.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.