High latency WAN scenarios?
The fact that Jazz is a distributed development effort (8 locations?) and that you are self hosting is a great test for the tool and shows that it can work for a real development team. What I'm wondering though is whether you've done any work on network monitoring within your environment or on other non-functional test environments?
Specifically, WAN network links between geographically distributed teams tend to have lower bandwidth, higher latency and higher risk of packet loss. IBM Rational's approach to this in the past has been the use of ClearCase/ClearQuest multi-site, which we've found to be incredibly effective even on reasonably poor networks. The approach that TeamConcert/Jazz is taking is one of a single server; and although I appreciate that the team server can be deployed on WebSphere, that's not going to help with poor network scenarios. Therefore, I was wondering if you've been doing any work to be able to provide guidance on typical network characteristics that would be required to run a Jazz based collaborative environment. Benchmarks from your own networks would be a great starting point and other recommendations for typical development teams would be a great follow up. To put this into perspective, if the Jazz teams have 10 Mbit connectivity and 50ms latency then you're an order of magnitude better than those of us restricted to a Megabit and 500 ms latency at best between teams. |
13 answers
Benjamin Silverman (4.1k●6●10)
| answered Sep 13 '07, 1:56 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I have only found one Work Item for HTTP performance (26414) benchmarking, rather than server performance over a WAN environment. You may want to create a work item for this to see if anyone has this information available.
|
|
Thanks for the suggestion; I'll wait a couple of days first before raising the RFE because this may end up just being a discussion point with no action required. Alternatively, it could end up that the action required is much more significant than merely producing network guidance (e.g. guidelines/support for production of multiple synchronising servers, similar to the multi-site setup).
Additionally, I've raised it here because members of the Jazz team asked me to when they were unable to answer my query at a recent RSDC conference in the UK; so I'm hoping that someone 'in the know' is listening and will come back with some answers ;-) |
leslie.jones@capgemini-dot-com.no-spam.invalid (lesojones) wrote in
news:fcdnng$jej$1@localhost.localdomain: I will raise this as an RFE if that's more appropriate, but I'm not Leslie, are you asking for things like, what did you test, how far were your teams, what network did you use, how many users as well as recommendations with regards to performance ? -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
|
Further to this, I've stumbled across this blog entry (http://www-03.ibm.com/developerworks/blogs/page/BillHiggins?tag=jazz) by Bill Higgins. In it he states that performance issues relating to the high latency WAN connectivity between the team in Zurich and the server in Raleigh, NC have been resolved.
It'd be great to understand the characteristics of the Zurich/Raleigh link to see how appropriately it maps to other cross-continent links. I will raise this as an RFE if that's more appropriate, but I'm not asking for an enhancement as such (at this time), merely clarification of the environment in which the distributed Jazz development are successfully working. |
|
That information would certainly be useful. The key here is understanding the limits; under what network conditions will the tooling be effective; at what point will it appear sluggish but still usable if you're patient; at what point will it be a non-starter.
I can certainly appreciate that you're doing some great work by self-hosting across the atlantic, but the characteristics of my cross-continent network links are going to be different from yours, so an understanding not only of the fact that you're doing it and have resolved some major performance issues but under exactly what conditions. |
Les said:
> Further to this, I've stumbled across this blog entry by Bill Higgins. In it > he states that performance issues relating to the high latency WAN > connectivity between the team in Zurich and the server in Raleigh, NC have > been resolved. Hi Les, FYI the blog entry you mentioned (http://www-03.ibm.com/developerworks/blogs/page/BillHiggins?entry=the_value_of_self_hosting) referred only to a single WAN-scenario - loading the Ajax UI code (JavaScript / HTML / CSS). It did not address the more general problem of transferring Jazz data (e.g. user info, work item info, etc.) over a WAN. > It'd be great to understand the characteristics of the Zurich/Raleigh > link to see how appropriately it maps to other cross-continent links. I'm afraid I don't have hard data on this link (though I'll ping some of the folks on the Zurich team to see if they do). With the Raleigh-Zurich code loading problem, the problem was that our initial implementation - loading each JavaScript / CSS / and HTML file via a sequential set of synchronous XmlHttpRequests was horrible. After that experience, Richard Backhouse and some other folks on the web UI team started spending significant cycles trying to figure out a design that would reduce the latency of code-loading over wide areas. The result is what we call 'dynamic Ajax optimization' (or just 'optimization' if you're amongst web UI people) and it's in pretty good shape, but we're always looking for ways to make code loading faster, so that the Ajax UI loads as fast as a normal web page (that's the goal anyway) and after it loads it should be much more responsive. Also please note that optimization will never be 'resolved'; we'll always look ways to make it faster and there are still a few knobs that we know we can turn which we just haven't gotten to yet. I can give you more details on dynamic Ajax optimization if you like, otherwise I'll ping the Zurich folks about details on their network link. > I will raise this as an RFE if that's more appropriate, but I'm not asking for > an enhancement as such (at this time), merely clarification of the environment > in which the distributed Jazz development are successfully working. I'd suggest that you open the Enhancement request at your earliest convenience. Even if we can't act on it immediately because of other priorities, it will still help by: 1) Giving us insight on what sort of functionality or documentation you are missing 2) Providing a forum for discussion to gain mutual understanding of your needs 3) Allow other community members with a similar need to join the conversation, voice their support, and monitor progress Feel free to cc me on the Enhancement request and I'll make sure it gets routed appropriately; also you may want to copy and paste the URI for this forum entry in the enhancement since there's some useful conversation here. |
|
I am unable to raise the enhancement work item via the website due to a "Permission denied" error.
I guess the options here are to either grant me permissions or, if someone else is willing to raise it for me, I'll post the details here for you to cut-n-paste. |
|
Les, sorry for the inconvenience.
Would you please tell me the exact wording of the "Permission Denied" message you're seeing? The only thing I can think of off the top of my head is perhaps you didn't set a category ... because your permissions look good. |
|
bhiggins wrote:
"Would you please tell me the exact wording of the "Permission Denied" message you're seeing? The only thing I can think of off the top of my head is perhaps you didn't set a category ... because your permissions look good." I have the category set to "Repository". The specific message I get (in a popup) is "Unable to save the work item. Details: 'Save Work Item' failed. Permission denied.". (FYI - If I set the category to "Unassigned" I get "Unable to save the work item. Details: 'Save Work Item' was blocked by process. The work item is not assigned to a category." - which seems sensible.) |
|
Thanks for the helpful information - we're investigating.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.