Software sizing isn’t easy

I’m going to quote pretty much the entirety of an introduction I wrote to an article just posted at the Deployment wiki on CLM Sizing (

Whether new users or seasoned experts, customers using IBM Jazz products all want the same thing: They want to use the Jazz products without worrying that their deployment implementation will slow them down, that it will keep up with them as they add users and grow. A frequent question we hear, whether it’s from a new administrator setting up Collaborative Lifecycle Management (CLM) for the first time, or an experienced administrator tuning their Systems and Software Engineering (SSE) toolset, is “How many users will my environment support?”

Back when Rational Team Concert (RTC) was in its infancy we built a comprehensive performance test environment based on what we thought was a representative workload. It was in fact based upon the workload the RTC and Jazz teams itself used to develop the product. We published what we learned in our first Sizing Guide. Later sizing guides include: Collaborative Lifecycle Management 2011 Sizing Guide and Collaborative Lifecycle Management 2012 Sizing Report (Standard Topology E1). As features were added and the release grew, we started to hear about what folks were doing in the field. The Jazz products, RTC especially, are so flexible that customers were using them with wonderfully different workloads than we had anticipated.

Consequently, we stepped back from proclaiming a one-size fits all approach, and moved to presenting case studies and specific test reports about the user workload simulations and the loads we tested. We have published these reports on the Deployment wiki at Performance datasheets. We have tried to make a distinction between performance reports and sizing guides. Performance reports document a specific test with defined hardware, datashape and workload, whereas sizing guides suggest patterns or categories of hardware, datashape and workload. Sizing reports are not specific and general descriptions of topologies and estimations of workloads they may support.

Throughout the many 4.0.x release cycles, we were still asked “How many users will my environment support?” Our reluctance to answer this apparently straightforward question frustrated customers new and old. Everyone thinks that as the Jazz experts we should know how to size our products. Finally, after some analysis and messing up countless whiteboards, we would like to present some sizing strategies and advice for the front-end applications in the Jazz platform: Rational Team Concert (RTC), Rational Requirements Composer (RRC)/Rational DOORS Next Generation (DNG) and Rational Quality Manager (RQM). These recommendations are based upon our product testing and analysis of customer deployments.


The article talks about how complex estimating a software sizing can be. Besides the obligatory disclaimer, there’s a pointer to the CLM and SEE recommended topologies and a discussion of basic definitions. There’s also a table listing many of the non-product (or non-functional) factors which can wreck havoc with the ideal performance of a software deployment.

Most importantly, the article provides some user sizing basics for Rational Team Concert (RTC), Rational Requirements Composer (RRC)/Rational DOORS Next Generation (DNG) and Rational Quality Manager (RQM). Eventually we’ll talk a bit more about the strategies / concepts needed to determine whether you may need two CCMs or multiple application servers in your environment.

For now, I hope we’re taking a good step towards answering the perennial question: “How many users will my environment support,” and explaining why it’s so hard to answer that question accurately.

As always, comments and questions are appreciated.

CLM 4.0.6 performance reports

A fresh batch of 4.0.6 datasheets was posted to the deployment wiki coincident with the 4.0.6 release. 4.0.6 was released February 28, 2014. Yes, that was a month or so ago, and so I’m late with mentioning the timely performance reports, our largest batch yet. The team worked hard to get the data and compile the reports.

For those keen on migrating data from ClearCase to Rational Team Concert, the ClearCase Version Importer performance report: Rational Team Concert 4.0.6 release report shows basic data on how long an import may take.

The Collaborative Lifecycle Management performance report: RTC 4.0.6 release shows that 4.0.6 RTC performance is comparable to 4.0.5.


For the RTC for z/OS 4.0.6 release, the Rational Team Concert for z/OS Performance in 4.0.6 report  shows that 4.0.6 performance is similar to 4.0.5. For 4.0.6 There were enhancements made to RTC for z/OS queries so that they use the Java JFS API: “In the scenario of the incremental build (request build after changing all the copybook files), the “Collecting buildable files” activity in preprocessing time improved about 25%, and result in an about 5% improvement in total run time.”

The Collaborative Lifecycle Management performance report: RRC 4.0.6 release report shows that RRC 4.0.6 performance is comparable to 4.0.5.

Similarly, the Collaborative Lifecycle Management performance report: Rational Quality Manager 4.0.6 release shows that RQM 4.0.6 performance is comparable to 4.0.5.

The CLM Reliability report for the 4.0.6 release demonstrates the capability of a Standard Topology (E1) configuration under sustained 7-day load.

The Collaborative Lifecycle Management performance report: Export Transform Load (ETL) 4.0.6 release report demonstrates that there are no performance regressions in 4.0.6 ETL performance compared to 4.0.5. The 4.0.6 ETL functionality is more comprehensive than it was for 4.0.5, and so there are situations where ETL times may have increased although the data now indexed is more complete and accurate.

Comments, questions? Use the comments box on the actual reports themselves.