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"