More timeouts on +templates page

I can't get to this page at all at the moment. The problem seems to be mostly non-SQL time, so we could use some profiling on the app server.

The query log looks very different today from when this bug first came up: we seem to count the POTMsgSets and Languages connected to a template (through TranslationTemplateItems and POFiles, respectively). Secondary to that we're also querying a lot of Persons. These queries could easily be made to run faster—there's no need why POTMsgSet and Language should be in those queries at all. But that's not going to help the non-SQL time, and these are very fast queries. Batching them would do more, but whether that would address the main source of non-SQL time would be just a guess.

One thing we *can* tell from the query log is that the non-SQL time is interspersed seemingly randomly through the rendering of the templates list. And that makes this a perfect candidate for TAL fragment caching.

OOPS-1529A2791, OOPS-1529C1970, OOPS-1529D195, OOPS-1529D197, OOPS-1529D2726
OOPS-1529C2396
OOPS-1529EA597, OOPS-1529EA598, OOPS-1529EA599, OOPS-1529EC644, OOPS-1529ED635

A UI improvement to this page made over 10.02 added a count of translatable messages to the templates listing. However instead of using the cached POTemplate.messageCount it used POTemplate.getPOTMsgSetCount, which is normally only used for recomputing statistics (and besides, was rather suboptimal). So some easy fixes there; fragment caching is still worth it though.

Turns out this was not urgent after all: these pages are not in use yet. Still, I've got a few cleanups.

Fixed in stable r11176 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11176>.

The fix here does improve a situation a lot. The page finally renders *sometimes* though it still times out a lot. I've filed a new bug 608349 for the new timeouts (they behave differently in that only non-SQL time is to blame now).

On Wed, Jul 21, 2010 at 6:33 PM, Данило Шеган <email address hidden> wrote:
> The fix here does improve a situation a lot. The page finally renders
> *sometimes* though it still times out a lot. I've filed a new bug 608349
> for the new timeouts (they behave differently in that only non-SQL time
> is to blame now).

Note that a trailing sql query shows as non-sql time sometimes.

-Rob

У сре, 21. 07 2010. у 19:42 +0000, Robert Collins пише:
> Note that a trailing sql query shows as non-sql time sometimes.

That bug should be fixed already. And no, this is non-sql time. We know
mostly where it is already (fmt:url and TAL rendering). See the
follow-up bug for details.