launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Wed, Aug 4, 2010 at 3:48 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> On 4 August 2010 17:33, Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx> wrote:
>> On Wed, Aug 4, 2010 at 9:46 AM, Robert Collins
>> <robert.collins@xxxxxxxxxxxxx> wrote:
>>
>>> Doing this will immediately close a half-dozen bugs, and focus our
>>> timeout and performance efforts closer to the actual source of our
>>> problems.
>>
>> Which bugs? The only open ones I'm aware of are feature requests which
>> I don't think are on anyone's radar to address.
>
> Milestones pages don't update when you close bugs targetted to the
> milestone.  It rather spoils the moment of closing your last bug.
>
> Likewise bug counts <https://bugs.edge.launchpad.net/malone/+bug/602936>.
>
> There are others.
>
> They can in principle be squashed individually but I don't know if
> it's worth it.

It needs to be fixed some time. If those values shouldn't be cached,
they shouldn't be cached. I tend to think making reload refresh is a
work around to the real bug (those values shouldn't be cached that
aggressively). Its also one of the features I don't think anyone would
be looking at soon anyway (although it would be quick if we wanted to
do it).

Turning off memcached is turning these two bugs into tech debt, and
throwing the baby out with the bath water.

> It might be helping with scalability but I don't think at the moment
> it's helping much with user perceived performance.  If something is
> slow (but not timing out) 76% of the time then being faster 24% of the
> time is not going to make Launchpad feel fast.  (It may be that it's
> much better than 24% on some particular pages and really poor on
> others; data welcome.)

It may not be helping with user perceived performance, but I can't see
it hindering it either. Of course, scalability improvements will help
user perceived performance second hand somewhat as more database
resources are available. I do believe it improves perceived
performance though on some pages, such as the bug index pages where we
cache the rendered comments. On first load we spend a *lot* of time
rendering the comments. I think we also get good cache reuse here, as
bugs become 'hot' where people working on them refresh the page and
when changes are made, people are notified and load up the page to
make their own comments.


> If it was making pages really dazzlingly fast 99% of the time and then
> occasionally they'd be slow that would be perhaps a good tradeoff; at
> least it might be lost in the noise of page loads sometimes being slow
> for reasons other than server side time.  Even then I don't think that
> giving confusing incorrect results is worth it.

So I don't see what the tradeoff is. We are trading scalability
improvements for what exactly? Being able to ignore half a dozen bugs?

> Perhaps we could turn memcached off entirely for a day or an hour and
> see if the oops rate or server load changes?

I don't think it will as we are not caching extensively enough yet but
I might be wrong. No matter the result, I don't consider this a good
reason to turn it off entirely. If we don't want to focus on caching,
that is fine and no change as nobody is focused on that anyway. As far
as I'm aware, the only people who have even used the facility are
myself and Curtis.

-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/