Which RTC topology do you recommend for a distributed environment?
![]()
Hi,
We are using RTC/RQM (4.0) in our company. It's a single instance that is acceded from many countries. We need to improve the performance for the users that are placed in a country different to the one where RTC is installed. Which topology do you recommend me to implement? I thought that the E3 topology (Enterprise - Clustered / Linux / Oracle) was the best option. However, I have just read the "Questionnaire for Clustering in the Rational solution for Collaborative Lifecycle Management" and it says that "Will the cluster live on a single site (the cluster will not span physical locations or buildings)?" must be YES. So, I´m a bit confused. What do you recommend me to do? I would really appreciate your help. Thanks |
Accepted answer
![]()
Hi
Clustering is not meant to cover the problem where you want "duplicate" instances in different sites - so that will not help. There are a lot of different options for improving performance. A great place to start is look at Dan Toczala's blog with pointers to some practical ideas about performance improvement. http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to-better-performance/ The rich clients (VS and Eclipse) tend to perform well anyway as they interact with the server in a clever way. Web UI performance is based on the overall network performance, your browser and (curiously) the distance from the application server running RTC/RQM and the database server. Put the database server very close (same subnet) as the app server. Also - consider upgrading to the latest releases (currently 4.0.2) as there are performance updates all the time that will help. IBM's own usage of RTC/RQM (for developing RTC and many of the other software group products) is very distributed, often across relatively slow WAN links - and the software is designed to cope with this. Hope that gives you a few ideas anthony Leonardo Marzo selected this answer as the correct answer
|
4 other answers
![]()
You can read my blog (at http://dtoczala.wordpress.com) which is a good discussion about things that will impact your performance. My next blog entry is going to be on sensible deployment architectures for Jazz solutions, but I may not get around to finishing it until sometime in early May. I have to get my Innovate materials finished first.
So in the meantime, I can give you a few quick things to keep in mind when looking at your Jazz solution architecture:
Comments Thanks Daniel. I found your blog very interesting
Hello Daniel,
|
![]()
I can't disagree on what Anthony said but additionally you can take a look at Scott's blog post and this might give you some perspective as well.
|
![]()
Thank you very much for your answers guys!
Our WAN is not so good, so we need to have multiple instances of RTC (but working as only one) in different countries. We need this not only for SCM, but also for RQM and workitems of CCM. Regarding E1-Distributed Linux, what I understand is that I can have the following architecture: Country A: - 1 server with JTS - 1 server with CCM - 1 server with RQM - 1 server with DB Country B - 1 server with CCM - 1 server with RQM Is that ok? Is it possible to have multiple instances of JTS? Is this a supported scenario? Thanks Comments 1
>have multiple instances of RTC (but working as only one)
1
Hi Leonardo
So, the unique alternative is to use caching proxies for SCM, and to improve the WAN performance as much as possible. Not supporting multi-site installation is a big limitation of the tool. Are there any plans to support it in the future?
far as I know, there is no plan to change the system design. these are independent servers that happen to share a licensing server. each CCM has its own unique database (repository).. this app is NOT one database with multiple processing engines in front (horizontal scalability). It is more like vertical scalability, one engine, one database, add cpu and memory.
![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One correction to the previous comment ... replication of change sets and change set history is supported. In particular, you can deliver changes from a workspace on one repository to a stream in a different repository to achieve this. Also note that you can use OSLC links to link across servers (but those are just "traversable" links for manual navigation and reporting ... so the only "semantics" they have is their effect on reporting).
|
![]()
As an additional remark, clustering for performance is not supported. Clustering is only intended for increasing availability.
|
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.