It's all about the answers!

Ask a question

CLM sizing questions


jeff thomas (542528) | asked Jul 28 '14, 9:22 p.m.
edited Jul 31 '14, 2:59 p.m. by Michelle De Armas (2612)
I've read the sizing document for CLM, but still not quite sure about things like number of users recommended for each tool in CLM.  I know quite a few factors play a role in answering this question.  but some general numbers would be helpful.  Is there a limit on how many users a jts server can support?  What makes you want to have more than one jts server?  When a business unit outgrows its, say rtc server in terms number of users, how do you add another rtc server and still make sure that you can have big picture information gathered from both rtc instances?  I have similar question for rrc and rqm.  Thanks!

Accepted answer


permanent link
Ralph Schoon (63.1k33645) | answered Jul 29 '14, 4:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jul 29 '14, 4:47 a.m.
Jeff,

these questions are incredibly hard to answer. I can just give you some hints on how to read the sizing documents and some hints about deployments I have seen.

It is almost impossible, from my perspective, to give good answers without being held liable for it, because the usage models can be completely different.
  • If you use only work items, the database will grow only slowly. Unless you upload many huge attachments.
  • If you use SCM the database will grow a bit faster, but still moderate. Unless you version huge binaries all the time or upload 20 years of source code history at the start.
  • If you upload DVD size movie pictures to your requirements or test results, the same.
  • 1000 developers that code and 1000 others that just write defects and browse plans have completely different profiles.
When is a database becoming big? That depends on the DB backend and how its architecture/storage is designed.

The performance obsessed people that write the sizing and performance documents and the information here: https://jazz.net/wiki/bin/view/Deployment/PerformanceWhereToStart often talk about concurrent users. Concurrent users is the number of users actively working on the server at the same time. For a given number of N users the number of concurrent users will likely be significantly smaller. Especially if the users are in different time zones.

On Jazz.net we have several 10ths of thousands registered users. However, the amount of concurrent users, I guess, is likely more in the area of some 100 users.

You should plan for an enterprise topology as described in the info center and the deployment Wiki. At the very least you should be able to grow to multiple machines by setting up a reverse proxy in the beginning. You should also talk to your IBM contacts, about sizing. Especially if your deployment is going to be in the region of thousands of users on one system.

If you have existing systems, what is their data? This can be a good indicator for what you can expect.

Today, there are only very limited capabilities available that can help you with outgrowing a server. It is in general hard (or impossible) to move data and projects with history and the like. You don't want to outgrow your deployment.
If the deployment is huge, consider splitting up the deployment into several CLM instances from the start. For example departmentalize. https://jazz.net/wiki/bin/view/Deployment/PlanForMultipleJazzAppInstances tries to give some hints on what to expect.
jeff thomas selected this answer as the correct answer

One other answer



permanent link
Michelle De Armas (2612) | answered Jul 31 '14, 2:58 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hello,
As a follow-up to Ralph's excellent comment, here is the link to the Deployment and installation planning section of the help. There are topics in that section to help in planning your deployment. 
http://www-01.ibm.com/support/knowledgecenter/SSYMRC_5.0.1/com.ibm.jazz.install.doc/topics/c_deployment_considerations.html?lang=en

Your answer


Register or to post 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.