Typical RTC performance
We're running 602 using Liberty w/ oracle backend, hosted on several RH VM's (one per app).
Numbers are inconsistent, just got one run with download/upload of 2300/1700, next run was 330/515. <o:p> </o:p>
At 2:37PM transfers are 996/1653.
At 2:38PM transfers are 646/1337. <o:p> </o:p>
At 2:39PM transfers are 2014/2898. <o:p> </o:p>
At 2:40PM transfers are 718/671. <o:p> </o:p>
The latency numbers are inconsistent as well.
One answer
Norman,
the download/upload rate per se tells you nothing about the RTC performance. It simply indicates current network conditions, possibly mixed with server conditions. In order to get a picture of your RTC performance and the factors influencing it, you need more complete monitoring: https://jazz.net/wiki/bin/view/Deployment/DeploymentMonitoring
which is fortunately built in, too.
At my previous work we used to rely on jazz monitoring through JMX, liberty monitoring, DB monitoring and have all that displayed in one Splunk dashboard. RTC performance will usually be influenced significantly by:
- database i/o and network accessibility
- thread / heapspace on your app server - some Liberty monitoring can be done via Liberty Admin Center
- general network throughput and latency
- LDAP availability
- so called "resource intensive scenarios" on RTC: https://jazz.net/wiki/bin/view/Deployment/CLMExpensiveScenarios
Notice that with the advent of server clustering (for RTC) in 6.0.4 we have a true and tested technology to scale a good performance to any number of concurrent users. But usually you only need this with well beyond 400 - 500 <concurrent> users (not users registered, but users actually logged in and creating load).
In your case if performance is varying I strongly recommend to start monitoring and correlating all key factors. In our setup we once found LDAP server had bad latency, another time found the DB was indirectly throttled due to a SAN cluster quota.
- Arne