I agree, with your comment about concurrent users. I nearly included this in
my earlier post. We are approximately 150 people, with 100 of these working
in the same office. I'd expect that we might have not more than 20
"concurrent" users ie: maybe
30 people attempting to create of update bugs all at the same time. Hit rate
might max out at 1500 hits per day ( ie: 1500 new or modified bugs ).
Thanks for the hardware description. Really helps.
, and I agree that an asynchronous emailing architecture will speed up
mailing.
Thanks for taking the time to respond.
"David Miller" <justdave (AT) bugzilla (DOT) orgwrote in message
@lists.mozilla.org
Mathew Butler wrote on 5/5/06 11:06 AM:
Is there any documentation anywhere that describes what tweaks are
required
to get adequate performance with "over 300,000 bugs"? at least a list
of
the types of issues that can be encountered from a performance
perspective?
The general performance of the Bugzilla web app has a lot more to do
with the number of users you have than the number of bugs in the
database. bugzilla.mozilla.org for example, gets about 200,000 hits per
day, and we have about 6500 active users.
Because of the way MySQL does table locking, you get a *huge*
performance boost by setting up MySQL replication to a slave server, and
having Bugzilla use the slave for queries (the shadowdb-related settings
in the params). I'm not sure how Postgres-based installations fare with
this. Postgres does locking differently so it might not be as big a
deal. But we've only just recently started supporting Postgres, so I
haven't heard a lot on the subject yet.
The other main performance issue people typically hit (even on smaller
installations) is trying to send mail. When users submit changes to
bugs, Bugzilla sends out the notification emails right then and there
while the submitting user waits. If there's a lot of people CCed on
that bug, or if your server is having DNS problems, the act of sending
that email can take a long time.
There's some tricks for making sendmail accept submitted email faster at
We're planning to get the mail sending moved out of the web application
in a future version of Bugzilla (so the webapp just queues it internally
to Bugzilla and an external process will actually send the mail).
that's done, the performance impact on changing bugs will be huge.
Just for comparison of hardware, bugzilla.mozilla.org is running on a 2
x 2.8 GHz Xeon box with 4 GB of RAM, with the MySQL database servers on
two additional similarly-configured boxes.