FAQ: AM performance and tuning
The purpose of this FAQ is to provide answers to commonly asked questions regarding performance and tuning for AM.
2 readers recommend this article
Frequently asked questions
- Q. Do I need to performance test AM?
- Q. How do I tune AM to improve performance?
- Q. How can I improve the performance of ssoadm?
- Q. What is the recommended Java™ Virtual Machines (JVM) heap size for AM?
- Q. Can I change caching in AM to improve performance?
- Q. How do client-side sessions affect performance?
- Q. What else might affect performance on a Linux® system or Virtual Machine?
- Q. Are there things I should monitor on an ongoing basis in terms of AM performance?
Q. Do I need to performance test AM?
A. Yes, performance testing is a very important step to ensure that the system you have configured will cope with the expected load once it is in production. By performance testing your system, you can tweak any performance issues you encounter before going live.
Before running any performance tests, you should ensure AM is running and configured in a test environment that closely resembles your planned production environment. You should also be aware of the type of load expected in your production system and the types of identity data involved to make your tests as realistic as possible. For example, you may want to test that your system can handle 20 authentications per second with a concurrency of 2,000 live sessions.
See Plan tests for further information.
Generating test identity data in DS is described in How do I generate sample user data for performance testing in DS (All versions)?
Q. How do I tune AM to improve performance?
A. Tuning AM is described in Tune AM.
Q. How can I improve the performance of ssoadm?
A. There are several approaches you can take to improving the performance of ssoadm as detailed in How do I improve the performance of ssoadm in AM (All versions)?
Q. What is the recommended JVM heap size for AM?
A. There are no definitive rules for the size of JVM heap size required as it will vary across individual environments and applications, but you should refer to Best practice for JVM Tuning with G1 GC or Best practice for JVM Tuning with CMS GC for best practice advice. There are also a number of things you should be aware of when making a decision for AM:
- AM response time is independent of heap size.
- The number of concurrent Single Sign On (SSO) sessions is dependent on heap size. As a rough guide, an AM server in production with a 3 GB heap can handle 100,000 sessions. As heap size increases, so does the number of possible concurrent sessions, however, smaller heap sizes are easier to manage.
- You must ensure you configure JVM garbage collection appropriately as garbage collection runs can get quite long if you have large heap sizes.
See How do I change the JVM heap size for AM? and Tune JVM settings for further information.
Note
For a 32-bit JVM or a 32-bit operating system, the limit for the process size is 4GB, that is, 2^32; this cannot be exceeded regardless of the amount of heap space allocated.
Q. Can I change caching in AM to improve performance?
A. Yes, you can improve performance in AM by configuring caching on the server side; you can configure caching for configuration data and global user data. This is described in Tune caching. You need to balance performance against memory usage when configuring caching; larger caches lead to fewer requests to AM but increase memory usage.
Q. How do client-side sessions affect performance?
A. Client-side sessions use more CPU than server-side sessions; however server-side sessions have higher RAM consumption.
See Choose where to store sessions for further information.
Q. What else might affect performance on a Linux system or a Virtual Machine?
A. Low entropy values can cause general system slowness.
Note
Low entropy values is an OS/Java/web container issue, which is independent of AM; as such, the suggested resolutions are outside the scope of ForgeRock support. If you want more tailored advice, consider engaging Deployment Support Services.
On Linux systems you can check if a low entropy value is affecting you by running the following command:
$ cat /proc/sys/kernel/random/entropy_availA response of 200 or less is considered low and should be addressed, but you may find that even higher values can cause system slowness.
Resolution
You can increase the amount of entropy available in a variety of ways; two possible approaches are:
- Use an external tool called RNGD (Random Number Generator Deamon). This can either use the RDRAND instruction set or /dev/urandom if RDRAND is not available, although many Virtual Machines (such as VirtualBox and OpenStack) passthrough the RDRAND instruction set to the VM. You will need to install the rng-tools package.
- Set the following JVM option in the application web container in which AM runs: -Djava.security.egd=file:/dev/./urandom
Q. Are there things I should monitor on an ongoing basis in terms of AM performance?
A. Yes, it is useful to monitor performance on an ongoing basis to allow you to react to changes quickly. Useful things to monitor include:
- Heap size
- Number of open sessions and size of sessions
- CPU utilization - utilization of 70-80% is worth investigating.
See How do I monitor session statistics in AM (All versions)? and Monitor AM instances for further information.
See Also
Very high CPU seen on ForgeRock products running on VMware
Performance tuning and monitoring ForgeRock products