We are using now 4.0.1 with 1200 Users worldwide. We use exclusivly the WebUI. Also for most administrative tasks. Eclipse UI is only used for some Admintasks which cannot be done in Web.

We are using Firefox 10ESR. IE is more or less unusable, specially in V8.

For far away locations with 200ms or more round trip we have a Citrix terminalserver infrastructure beside the Jazzserver with Firefox on it.

Our plans are often 1000+ workitems. Specially Release Plans and Product Backlogs.

I fired many workitems against planing to improve the stability. With V.4.0.1 we are now at a quite stable release and also the performance is acceptable. With V.3.0.1 nd V.4.0 I often asked myself, why did I decided to rollout only the Web client.

Drag and Drop in a Workbreakdown view is very dangerous. We recommend to select the workitem(s) you want to move, go to the target and use the Move above/below/into menu instead of drag and drop. Also the new autoscroll function is not improving this. Specially in a Ranking View with Workbreakdown structure it's absolutly dangerous to use drag and drop. Drag and drop should only be possible within the siblings in a ranking view.

The new function to select all children with the <Alt> key and the new select all function within groups helps also in this area. But it's not understandable when you select a parent, why are not all children also selected per default. Most user forget to press the <Alt> key when the select the parent.

is this RTC3?  the plan views are very slow.. make sure to use Firefox or Chrome.. IE is a dog as plan is all javascript..

no performance improvments in 3.x  everything is in 4.x and forward.. we've been told by IBM that plans should be small <200 workitems) for 'best' performance..  course release and backlogs are much larger..

yep, a dead UI (no threads polling for changes) will experience those concurrent update problems more often than Eclipse for example..

drag/drop in the web UI I don't use much.. its painful as u mention

Evan,

  More of what Sam and Guido have already stated here.

  When a user requests a plan, the request is sent to the Jazz server and the usual authentication, permission, and context setting is done.  The Jazz server will then generate a series of SQL requests to the database to retrieve all of the work items that need to be displayed for a plan.  Once the data sets have been returned, all of this data is returned to the client.  If the client is a web browser, a Javascript routine is then run, which will properly display and render the plan for the end user.  The use of Javascript on the web client to do this work is because plans are active elements, and users can interactively modify multiple work items when doing drag and drop operations and other modifications while looking at a plan.

  Since the JavaScript being executed for plans is fairly complex, the performance of the JavaScript engine in the browser has a direct impact on the perceived end user performance.  Curious users might want to measure the performance differences between the various different web browsers using a tool like Firebug or HttpWatch.

  Since a plan retrieves data for multiple work items, it is like a large query in the way that it requests data and gets large collections of data returned to it.  The main difference is that this data is not just returned to the end user in the form of rows of data.  Instead the plan display must do some amount of JavaScript processing in the web browser to render the final plan display for the user, similar to the way that the reporting engine will need to use the data returned to it to render a diagram for the report.

  Plans can be slow when they become very large, due to the large amounts of data that need to be returned from the database, and the subsequent JavaScript processing in the web browser.  At the present time it is an accepted best practice to limit plans to less than 250 plan items.  Larger plans can take a long time to display, and most of the time a user cannot conceptually grasp more than a few dozen plan items at a time.

In addition to the commentary above.. all the data is NOT processed in one batch in the web UI.

the list of workitems may be returned in one blob, but the rest of the plan data is retrieved in a per workitem loop.

our measurements show about a 5 to 1 web service calls per workitem.. so this web UI is VERY chatty.
and every step along the implementation path contributes..  a few ms on a database look on every workitem makes a difference when i hit 500 or a 1000 workitems. ( we had one fun time a few months ago when someone unrelated was doing a 4 hour ftp download across the same phone line, completely consuming the capacity, and elongating normal response time from 20ms to 90ms..  4.5 times longer.. and it showed.. the scrum meeting had to be canceled)

we measured for 500 workitems at over 3,000 web service calls.  this is old school (early 90's) client server design which works great for small data.(I helped design and write some of them with the same problem back then) and takes lots of thought on how to minimize these kinds of design side effects with larger data..

I think IBM understands the issue, but its gonna be really hard and slow to resolve.. (incremental change over time)

We support over 9000 users across many repositories and the majority of our users use the Web Client.  While I agree the Eclipse Client can be easier for Planning purposes, it still works well in the Web Client with Firefox and a lot of our users would prefer not to use the Eclipse client if they can help it. 

and a lot of the planning functions are and will only be available in the web UI.. (starting with 3.0, IBM has started doing web only implementations of new function)..