Bug 584959 - RFE: Separate Bugzilla servers in other geographic locations.
RFE: Separate Bugzilla servers in other geographic locations.
Status: CLOSED NOTABUG
Product: Bugzilla
Classification: Community
Component: Database (Show other bugs)
3.6
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: Simon Green
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-22 15:29 EDT by David Lawrence
Modified: 2014-10-12 18:46 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-19 23:26:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2010-04-22 15:29:14 EDT
Separate Bugzilla servers (master/master replication) allowing for Bugzilla servers in other geographic locations.
Comment 1 Max Kanat-Alexander 2010-05-26 17:54:12 EDT
  Instead of doing this, I'd suggest putting Bugzilla's static files into a CDN and serving the dynamic pages centrally. The dynamic stuff would be slow still, latency-wise, but that's just a single page load, so a 100ms latency wouldn't matter. I think it's the latency of checking for updates on CSS, JS, and image files that probably kills international performance, although I can't prove that.
Comment 2 David Lawrence 2010-05-27 17:43:19 EDT
Thats an option. We do want to have multi-master databases set up eventually in other locations as they want to data mine directly to the database for metrics reports, etc. Our pipes from Europe, China and AUS to our colo in Phoenix AZ where Bugzilla is located are notoriously slow.

One thing reminds me when you mentioned CDN is that one of our to-do's is to make Bugzilla rate better with  Y-Slow but I seem to remember talk upstream of doing that as well.
Comment 3 Max Kanat-Alexander 2010-05-27 20:05:10 EDT
Okay. Perhaps the metrics should go into a separate database? Multi-master is very hard to do. Two-phase commit is unreliable and means that the fastest that any node can commit is however quickly the *slowest* node can commit.

As far as YSlow goes, yes, I might start running that or the Google tools against Bugzilla, but in order to do that, I personally need an environment where any of those issues are actually significant for a real user.
Comment 4 David Lawrence 2010-06-01 17:33:38 EDT
(In reply to comment #3)
> Okay. Perhaps the metrics should go into a separate database? Multi-master is
> very hard to do. Two-phase commit is unreliable and means that the fastest that
> any node can commit is however quickly the *slowest* node can commit.

Yeah we tried some initially trials of this in the past and ran into issues so we backed off for the time being. But it has always been something on the back burner that we would like to try again.

We do currently have our metrics tools pointing to our internal read-only slave. 
So we are not concerned with the metrics tools affecting Bugzilla performance. Only the Bugzilla code itself can access the actual master. Another idea we have had is to create a separate server xmlrpc.bugzilla.redhat.com for handling all XMLRPC requests and take some of the load from the main webapps. A large percentage of our traffic is from XMLRPC clients internally.

> As far as YSlow goes, yes, I might start running that or the Google tools
> against Bugzilla, but in order to do that, I personally need an environment
> where any of those issues are actually significant for a real user.    

Well we are more than willing to try any patches on our live servers to help increase compliance and performance.
Comment 5 David Lawrence 2010-10-28 01:21:47 EDT
This is not a blocker for the first JIRA migrations.
Comment 8 Simon Green 2012-06-19 23:26:36 EDT
I can't see this being on our roadmap in the foreseeable future.

  -- simon

Note You need to log in before you can comment on or make changes to this bug.