Hi Bjorn, I'm really interested in performance for Launchpad and would love it if you could expand on the performance figures you saw.
I guess in LEAN terms I'm pressing the little red stop the line button. >From your LEP page performance section, you see accessing 40 bugs out of 50K go from 1100ms to 1300ms - an 18% increase and 1/5 of a second in real terms - per 40 bug page. Now, if thats as part of a refactoring that should eventually speed things up, its tolerable, because being stuck in a local minima that is globally non-minimal would be a pain. I didn't see any implications that that is the case here though - so if its actually a new overhead going to be worn everywhere in the system, I think we should measure some more and think harder about the design to see how we can address the overheads. The reason I think that its important to stop and think about this now, is that real servers often perform *worse* than workstations: while they have more memory so can handle a larger working set, they also have more users accessing a greater variety of content concurrently. So a local workstation test that is slower is usually a very good sign that it will be slower in production too - unless one is deliberately designing to make use of a large memory pool for some task (e.g. bug analysis or something on a dedicated server). We don't have a 'never make launchpad slower' policy, but I think its very concerning when a new feature is as dramatically slower as you're reporting this one is. I found when tuning commit in bzr 1.0 that there was a hard lower limit we couldn't get below - we did some full tree XML stuff, and that required us, under all circumstances, to work with the entire dataset. So performance work there was tricky, as really there was a constant overhead affecting the measurements; when that was eliminated, I could much better evaluate the relative improvements / costs I was achieving. And it was from that work that we got the status overheads down as low as it is (over a series of releases - no magic bullets :(). I wonder if there are similar issues here, as Launchpad is in a similar place. Perhaps looking at the query breakdown (use the ++oops++ decorator on a URL, and then you'll get an oops logged that oopstools can analyse for you) might show up where the extra time is coming from. If theres anything I can do to help with this - whether reviewing the design, just chatting on IRC or voice, or whatever - let me know; I want ACLs, and I want Launchpad to be fast, and I'm sure we can do it. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
