ForgeRock Identity Platform
Does not apply to Identity Cloud

FAQ: AM performance and tuning

Last updated May 10, 2022

The purpose of this FAQ is to provide answers to commonly asked questions regarding performance and tuning for AM and Agents.

2 readers recommend this article

Frequently asked questions

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 Planning 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 Tuning Instances.

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 (All versions)? and Tuning JVM Settings for further information.


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 Tuning 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-based sessions affect performance?

A. Client-based sessions use more CPU than CTS-based sessions; however CTS-based sessions have higher RAM consumption.

See Choosing 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.


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_avail

A response of 200 or less is considered low and should be addressed, but you may find that even higher values can cause system slowness.


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. Which Apache httpd Multi-Processing Module (MPM) should I use with Web Agent?

A. It is recommended that you always use Worker MPM rather than Prefork MPM. You should ensure there are enough processes and threads available to service the expected number of client requests. You can then tune the Worker mode performance in the conf/extra/http-mpm.conf file as detailed in Tune Apache Multi-Processing Modules.

You can check which MPM Apache is using with the following command:

$ apachectl -V

The MPM in use is shown against Server MPM.


Turning off the Apache™ KeepAlive feature can potentially improve performance as well since the KeepAlive feature increases memory usage. You should test your performance with KeepAlive enabled and then again with it off to check what impacts it has on your setup.

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 Monitoring Instances for further information.

See Also

Very high CPU seen on ForgeRock products running on VMware

FAQ: General AM

Performance tuning and monitoring ForgeRock products

Related Training

ForgeRock Access Management Core Concepts (AM-400)

Copyright and Trademarks Copyright © 2022 ForgeRock, all rights reserved.