The Future of Performance: Scaling

Max Kanat-Alexander mkanat at
Fri Dec 19 13:46:31 UTC 2008

	So, I was reading this:

	And it was a good reminder of something that I've known
for a long time, but sometimes had forgotten--the future of performance
is, by and large, *scaling*, not optimizing. That is, tweaking our code
is not the important thing--what's important is that people should be
able to throw *more hardware* at Bugzilla to make it faster, if they
need to.

	We have very few real optimization issues that need to be
handled, and that is it, really:

	* Sending email needs to be faster:

	* Any page with lots of products/components/versions is slow
	  because of our JS:

	* Bugzilla can be generally slow if you have lots of products
	  or groups. (This one is lower-priority than the two above,
	  though, because you really have to have a LOT of products to
	  start noticing this.)

	Other than that, if we want to focus on performance, we should
be focusing on things like "Where can we use the shadowdb more?"
In fact, scaling the database is probably the most important performance
issue for us to tackle after the three above.

	All other performance issues, I pretty much don't care about,
personally. I'd rather see some simple code than some minor tweaks
to make things fast. It's nice to optimize some SQL here and there, but
if we could just make the database layer *scale*, it wouldn't even
matter that much how many SQL calls we were making.

	Now, honestly, scaling Bugzilla isn't *that* important yet--we
have very few enterprise-level users who really need it to scale
massively. But as we move more and more into that space, that's the
area of performance that will really start to matter. So the *future*
of performance in Bugzilla will be scaling, and *that's* the area we
should start to focus on, performance-wise.

Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

More information about the developers mailing list