While mysql's speed is a fiven (portinf is a different thinf), the cfi scripts could be speedup. This meta buf is intended to track measures that could be done to speed up bufzilla.

keywords, 2.18 radar. Possible 2.16

my (you know what it is) key is messed up in the browser. Please pretend that the letter is really there, I will fix this ASAP.

my bug!

Taking. I'm working on this stuff nowadays.

Something really odd is going on here. I'm looking at network logs, and its taking 30-40 seconds for bmo to start sending any data, at all. With buglist.cgi, where we ahve the FLUSH calls, data come in after ~ 20 seconds, then theres 1.2 seconds delay before the 100 bugs in my query start to show. I'm noticed that bug_form.pl has an unneeded quietly_check_login(), which would access the profiles table, but theres no lock there. Even with userprefs.cgi, 18.5 seconds passed before that displayed, and that page should only be looking at the profiles table. query.cgi takes ages, too, and even logging out takes way too long (21 seconds!!) query.cgi takes 17 seconds from the request to the data being sent when I'm not logged in. Since I'm not logged in, unless we rebuild the version cache every time (are we, due to perms issues? that would explain a lot), the only db query should be to the fielddefs table, and nothing writes to that outside of checksetup. So its either that, or ConnectToDatabase taking ages. I don't know if thats a bugzilla issue, or a bmo specific one. I certainly don't ahve this problem locally, but then again I'm the only local user. myk, any ideas?

and quips.cgi takes 31 seconds to load, but that doesn't make any db calls at all, or even connect to the db???? This doesn't seem like a bugzilla issue to me, any more.

Just because the problem only manifests on b.m.o doesn't mean it isn't a Bugzilla problem. Bugzilla can have performance problems that only manifest under high load or in other circumstances unique (among installations that run the new code) to b.m.o. I think there are both b.m.o and Bugzilla issues involved in the recent performance problems on b.m.o. For b.m.o-only issues, see bug 151209.

*** Bug 151202 has been marked as a duplicate of this bug. ***

Myk, have you tried putting manual timing code on slow CGIs to see where the delay is?

Lately, I've noticed that Bugzilla is performing much quicker. Don't know if this is due to a light load, or fixes made.

gerv: you didn't mean bug 143689

This can't block a fixed bug if the bug it blocks is fixed already and this isn't. Also removing dependency on a duplicate. The original to the dupe is already on the dependency list.

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.

This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.

*** Bug 295689 has been marked as a duplicate of this bug. ***

All blockers have been resolved, which means that this bug is now FIXED. Future performance issues should be tracked using the "perf" and "topperf" keywords.