The Future of Performance: Scaling

[David Marshall]

On 1/8/09 8:23 PM, "David Miller" <justdave at bugzilla.org> wrote:


> 
> Although, thinking about it...  searches are the main thing that take
> lots of time and cause replication lag.  What if Bugzilla itself knew
> about two distinct slave servers, and used one for bug searches, and the
> other for everything else?  Then the "everything else" one would almost
> always have almost zero lag because the rest of the queries Bugzilla
> runs are so quick.

We do something like that at Yahoo!, where we have 3 slave database servers
plus one slave that we use for "slow queries," which are heuristically
identified in Search.pm.  We don't put all searches to this slow query
server, because most searches are very fast, such as "bugs assigned to me,"
and we don't want to throw them in with the really slow queries.

One idea that we chose not to implement is to make replication updates on
this slow query server (or any slave, for that matter) be LOW_PRIORITY so
that they are only applied when there's not a query already going.  This
risks lengthy replication lag for what may be significant performance gains.
(We decided that we didn't want our replicas to have stale data, but YMMV.)

We have some really fancy stuff for improving search performance, now that
we're making a maximum effort to merge with Mozilla's HEAD, I hope that
we'll get this upstream sooner rather than later.