- Q. Do I need to performance test DS?
- Q. How do I tune DS to improve performance?
- Q. What is the recommended way to load balance client connections?
- Q. What is the recommended Java® Virtual Machines (JVM) heap size for DS?
- Q. Can I change caching in DS to improve performance?
- Q. Are there things I should monitor on an ongoing basis in terms of DS 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 DS 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 user data involved to make your tests as realistic as possible.
Generating sample data in DS is described in: How do I generate sample user data for performance testing in DS (All versions)?
A. Tuning DS is described in Performance Tuning.
A. In most scenarios, the way to load balance client connections is specific to your topology so we don't have definitive best practice recommendations. You may want to have pooled connections so that clients only open a set number of connections or your clients may not be able to pool connections and open individual connections for each request.
In either case, you may or may not want to load balance based on:
- Number of opened connections.
- System load of the DS server.
- Round robin.
- Failover only
You should consider setting an idle time limit to ensure idle connections are closed; in particular, you must set this lower than the idle time limit for the load balancer as detailed in Idle Time Limits if you want more tailored advice, consider engaging Deployment Support Services.
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. You can use the size of a backend after doing an initial import-ldif of all the expected data to give you an indication of the size required and base your initial heap size on this.
See How do I tune DS (All versions) process sizes: JVM heap and database cache? and Java Settings for further information.
You must ensure you configure JVM garbage collection appropriately as garbage collection runs can get quite long if you have large heap sizes.
A. Yes, you can improve performance in DS by configuring the database cache and entry cache, although entry caches are generally not used in DS (unlike ODSEE). This is described in How do I tune DS (All versions) process sizes: JVM heap and database cache?, Database Cache Settings and Cache for Large Groups. You need to balance performance against memory usage when configuring caching as larger caches lead to improved performance but increase memory usage.
- Heap size.
- Number of open sessions/size of sessions.
- CPU utilization - utilization of 70-80% is worth investigating.
See Monitoring Guide, FAQ: Monitoring DS, How do I use cn=monitor entry in DS 5.x and 6.x for monitoring? and How do I collect data for troubleshooting high CPU utilization on DS (All versions) servers? for further information.
You should also ensure the access log file is enabled; this log file contains information about operations the server process. This is described in About Logs.