On Wed, Aug 4, 2010 at 3:48 PM, Martin Pool <[email protected]> wrote: > On 4 August 2010 17:33, Stuart Bishop <[email protected]> wrote: >> On Wed, Aug 4, 2010 at 9:46 AM, Robert Collins >> <[email protected]> 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 <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
