Some things to consider when reading the current version of the report include 
the following...

1. Machine sizes and configuration. The deployment does not reflect a 
production environment or one that BMC would perform load and scale testing on 
in our lab – this is a reference environment that we would use to confirm Load 
scripting and general product regression testing and confirmation. Also, the 
report indicated OOTB configuration. BMC has tuning guidelines that are 
specific to load testing across the versions under test. These settings and 
tuning characteristics are also the ones we deploy in customer environments 
when they have scale requirements.
2. Scale. At scale and under load the CPU cycles are maxed out in your 
environment. Remedy is a CPU bound application and so once load impacts CPU 
beyond 80% then the hardware needs to be scaled in order to get accurate 
performance load results. We would never recommend our customers to run that 
usage load on a server that is exhibiting CPU activity at or close to 100% 
usage. We also carry this same methodology into our performance scale lab. We 
always recommend no more than 80% CPU load on a single VM or server instance.
3. Memory usage. V9 does use more RAM/Virtual memory than v8 because it is a 
JAVA application. BMC has compared this usage in the lab and we monitor for 
memory usage and related GC activity. Sizing the application under load will 
reveal how much RAM memory is required and then the JVM start size can be tuned 
to maximize the JVM and application performance.
4. Performance. BMC’s own internal testing of performance and scale with Remedy 
9, on a right-sized, tuned and configured environment is showing different 
results than those observed in the report. BMC sees a similar number to 8.1 in 
some use case scenarios while in others we actually see better performance and 
scale. We did not observe areas where performance regressed and if we had then 
this would have been a release gating defect. Lastly, there were some targeted 
areas that we focused on making significant improvements in performance that 
were not highlighted in the report. FTS-based search speed increased by up to 
11 times and CMDB reconciliation throughput more than doubled.
5. Codebase. It’s unclear if this is run using BETA code or the GA code in the 
report.

Thanks, TM

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to