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.

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.

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.

(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.

This is not a blocker for the first JIRA migrations.

I can't see this being on our roadmap in the foreseeable future.

  -- simon