Merge lp:~sinzui/launchpad/cache-tweaks-0 into lp:launchpad
| Status: | Merged |
|---|---|
| Merged at revision: | 10934 |
| Proposed branch: | lp:~sinzui/launchpad/cache-tweaks-0 |
| Merge into: | lp:launchpad |
| Diff against target: |
356 lines (+152/-66) 11 files modified
lib/lp/answers/templates/faqcollection-portlet-faqs.pt (+1/-1) lib/lp/blueprints/browser/tests/test_hasspecifications.py (+34/-0) lib/lp/registry/browser/configure.zcml (+5/-0) lib/lp/registry/browser/milestone.py (+3/-1) lib/lp/registry/browser/person.py (+1/-1) lib/lp/registry/browser/tests/milestone-views.txt (+23/-0) lib/lp/registry/templates/distroseries-portlet-packaging.pt (+1/-1) lib/lp/registry/templates/milestone-index.pt (+16/-59) lib/lp/registry/templates/milestone-macros.pt (+65/-0) lib/lp/registry/templates/productseries-milestone-table-row.pt (+2/-2) lib/lp/soyuz/templates/distroseries-portlet-architectures.pt (+1/-1) |
| To merge this branch: | bzr merge lp:~sinzui/launchpad/cache-tweaks-0 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gary Poster (community) | Approve on 2010-05-27 | ||
| Michael Nelson (community) | code | 2010-05-27 | Abstain on 2010-05-27 |
| Jelmer Vernooij (community) | code* | 2010-05-27 | Approve on 2010-05-27 |
|
Review via email:
|
|||
Description of the Change
This is my branch to adjust the cache rules for pages.
lp:~sinzui/launchpad/cache-tweaks-0
Diff size: 357
Launchpad bug: https:/
Test command: ./bin/test -vv \
-t milestone -t test_hasspecifi
Pre-
Target release: 10.05
Adjust the cache rules for pages
-------
Edge timeout reports a report a reduction of 50%-80% in timeouts in the pages
that were added. Timeouts still happen for all cached pages though. In the
case of milestones, the caching is too long. Release managers need to see
milestone changes; consider using different cache rules for active milestones.
Rules
-----
Look at the timeouts on edge reported in in the oopses. Identify the slow
chunks.
QA
--
Verify distroseries, project and project group milestone pages
verify the launchpad team spec workload page loads.
verify maverick loads
Lint
----
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Test
----
* lib/lp/
* Added a rudimentary test for the batch size change.
* lib/lp/
* Added a simple test to verify that the milestone bugtask cache rules
are based on the state of the milestone.
Implementation
--------------
* lib/lp/
* Increased expiration age because FAQs do not change every day. This
may help project and project group pages.
* lib/lp/
* Registered +milestone-macros so that the milestone bugtask table
can have different cache times.
* lib/lp/
* Assembled a menu that is fast to use (no subscription link) when
working with many milestones. Many pages iterate over milestones and
provide links to work with them in the list. The oopses indicate the
timeouts happen when setting up the bug subscription link that is not
used!
* lib/lp/
* Decreased the TestPersonSpecW
75 to 20. I *hope* this fixes the issue on edge. I really cannot
see if the issue is members or the number of specs, but I know the
team in the oops is ~launchpad. I think this oops is ironic since
the launchpad team abandoned blueprints.
* lib/lp/
* This is still a common cause of oopses. Until the queries can be made
faster, the cache expiration age should be increased to 3 hours.
* lib/lp/
* Use a menu without the subscription link when working with inline
links to avoid repetitive db look ups.
* Extracted the bugtask table to a macro so that the cache time can
be different for active milestones. We are getting timeouts on lucid
milestone pages are are inactive--they cannot change. 1 hour
expiration age is too long for release managers that are working with
active milestones. This invasive refactoring permits active milestones
to cache for 10 minutes and inactive one to cache for 3 hours. This
helps distro, project and project group milestones.
* lib/lp/
* Extracted the milestone bugtask table and wrapped it in a macro for
reuse.
* lib/lp/
* Use a fast menu when creating milestone links. This helps the project
and distro series pages as well as the +series page.
* lib/lp/
* Architectures do not change after they are set, so cache the portlet
longer. This may help the distroseries page.
| Michael Nelson (michael.nelson) wrote : | # |
I can look at this tomorrow, but have to run right now... so assuming you're keen to land this now, can you please request a review from someone else? Thanks.
| Gary Poster (gary) wrote : | # |
Thank you, Curtis. This sounds like a big improvement, and looks very cleanly done.
Notes:
- The testing of the cache changes--looking for comments that duplicate your cache settings--is not ideal. Could you create a bug for foundations giving an example of the kinds of tests you were trying to write, requesting a better testing pattern? Vaguely and naively, I would think we ought to have some test cache available that lets you ask questions about what is cached and for how long. The Foundations deliverable for the bug perhaps should be a refactoring of one or more of your tests, to show that our changes address the problem.
- Similarly, the fact that you had to create a macro simply to conditionally change the wrapping cache settings is broken. I'm fine with this as a temporary solution, but I'd like Foundations to provide a nicer spelling, or at least be challenged to do so. That said, nothing comes to mind initially. :-/ But anyway, a bug is probably appropriate. We can always promote a technique (see next bullet point) rather than changing the syntax, if that's what we decide is the better solution.
- I'm pretty confident it would be possible to put the macro in the template itself, so that you didn't have to make a separate file for it. That's the way I would have tried to do it, since this macro is only used locally. You could have used define-macro within the first block, and then use-macro in the second block. I forget how to address the local macros: it might be template/
<!-- milestone_bugtasks cache:private 10 minute -->
<!-- milestone_bugtasks cache:private 3 hour -->
| Curtis Hovey (sinzui) wrote : | # |
On Thu, 2010-05-27 at 16:00 +0000, Gary Poster wrote:
> Review: Approve
> Thank you, Curtis. This sounds like a big improvement, and looks very cleanly done.
>
> Notes:
>
> - The testing of the cache changes--looking for comments that
> duplicate your cache settings--is not ideal.
I reported [Testing tal cache states could be easier]
https:/
> - Similarly, the fact that you had to create a macro simply to
> conditionally change the wrapping cache settings is broken.
I reported [tal cache: directive could support an age variable]
https:/
> - I'm pretty confident it would be possible to put the macro in the
> template itself, so that you didn't have to make a separate file for
> it. That's the way I would have tried to do it, since this macro is
> only used locally. You could have used define-macro within the first
> block, and then use-macro in the second block. I forget how to
> address the local macros: it might be
> template/
> this in before PQM closes this evening (and maybe you'd want to argue
> the style), so I'm OK with you not pursuing this. Anyway, here's my
> untested example:
>
>
> <tal:has_bugtasks condition=
> <tal:active content=
> condition=
> <!-- milestone_bugtasks cache:private 10 minute -->
> <tal:milestone-
> metal:define-
> IMPLEMENTATION GOO GOES HERE
> </tal:milestone
> </tal:active>
> <tal:inactive content=
> condition="not: view/milestone/
> <!-- milestone_bugtasks cache:private 3 hour -->
> <tal:milestone-
> metal:use-
> </tal:inactive>
> </tal:has_bugtasks>
I tried something similar, but it was getting test errors in some
conditions. I'll keep the macro for now. If we can get the variable age
issue solved I could remove the macro.
--
__Curtis C. Hovey_________
http://
| Robert Collins (lifeless) wrote : | # |
I suggest invalidating pages as backend content changes - this is what
yahoo do for their news site - and they have more volume than we do :)
I'm happy to chat about how anytime you like - or even arrange some
time with Mark Nottingham to detail what they do.
| Curtis Hovey (sinzui) wrote : | # |
We do not have an api to invalid all cached junks that involve an object. Having one would really simplify situations where users update bugs that are linked to a milestone. The automatic key generation needs rethinking.

Thanks!
My tal knowledge is still pretty basic so it would be great if somebody else with more tal knowledge could also have a look; I understand what's happening but I'm probably not aware of all of the caveats.