- 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-based sessions affect performance?
- Q. What else might affect performance on a Linux® system or Virtual Machine?
- Q. Which Apache™ httpd Multi-Processing Module (MPM) should I use with Web Agent?
- Q. Are there things I should monitor on an ongoing basis in terms of AM performance?
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.
Generating test identity data in DS is described in How do I generate sample user data for performance testing in DS (All versions)?
A. Tuning AM is described in Maintenance Guide › Tuning Instances.
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)?
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 Maintenance Guide › 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.
A. Yes, you can improve performance in AM by configuring caching on the server-anside; you can configure caching for configuration data and global user data. This is described in Maintenance Guide › Tuning Caching. You need to balance performance against memory usage when configuring caching; larger caches lead to less requests to AM but increase memory usage.
See Sessions Guide › Choosing Where to Store Sessions for further information.
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
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 Web Agents User Guide › Tuning 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.
- 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 Maintenance Guide › Monitoring Instances for further information.