Novell Cool Solutions: Feature
Digg This -
Posted: 30 Nov 2005
Note: This summary article is adapted from BrainShare presentation DL 155. The two main sections are Hardware Considerations, and Large Tree Performance and Scalability Tuning.
There are four basic hardware considerations to keep in mind as you look to eliminate performance bottlenecks in your eDirectory system:
- Disk - I/O is the key to disk performance
- CPU - balance quantity vs. quality
- Memory - how much is too much?
- Network - get the right amount of network hardware
Each of these considerations is discussed below.
Certain actions will cause eDirectory to write to disk. Examples of these are modify/add/delete operations, and authentication with "Login Update Enabled" turned on. RAID Level 1+0 is also recommended.
When you consider SAN vs. DAS vs. NAS vs. internal, remember that Disk Cache plays a role. Calculate your overall disk I/O speed, factoring Sequential Writes vs. Random Writes.
The key to all this is in the proper handling of Disk Aggregation.
The general rule for CPU performance is in two parts:
- Quantity (SMP) - more CPU's equals more load (bandwidth, connections)
- Quality (Speed) - a faster CPU equals more transactions/second (throughput)
Although it is more complicated than this, you should be able to anticipate CPU performance behavior using this general rule.
To get the right CPU balance for your needs, you may need to do some processor scaling. Processor scaling can be forecast using Amdahl's Law:
Scalar = (1-f) + f / # of Procs MPTrans/sec = SPTrans/sec * Scalar
Sample scaling is illustrated below:
Figure 1 - Multi-processor performance scalar
Actual performance tests can be used to validate calculations, as shown below:
Figure 2 - Calculated vs. measure TPS
For NDSD/DHOST memory usage, eDirectory memory consumption can be split into three areas:
- Flaim Database Cache
- NDSD/DHOST Process, including LDAP, Novell Audit, and Novell Identity Manager
- Worker Threads
eDirectory Memory Configuration should take into consideration Database Cache - static or dynamic - and Dirty Cache.
10,000 LDAP client requests to four replicas can cause 80MB of traffic across a Gigabit Ethernet network. The bigger the requested LDAP attributes (for example, returning all of the attributes of 2 million users under an OU), the more bandwidth consumed.
Also, tests have shown that using LDAP over SSL results in an average of 10% performance hit due to CPU encryption latency.
Large Tree Performance and Scalability Tuning
As you tune a larger tree for better performance and scalability, there are three main factors to consider:
- Cache Settings (Database and maximum/minimum Dirty Cache)
- Replication threads
- Worker Process threads
Cache Settings for eDirectory Optimization
In iMonitor you can adjust the Database Cache by using the Agent Configuration option:
Figure 3 - Adjusting the Database Cache
You can also adjust the Dirty Cache Settings in the eDirectory DIB directory (_NDSDB.INI). Notice the settings for the upper limit (maxdirtycache) and the lower flush limit (lowdirtycache) in the screen below:
Figure 4 - Adjusting Dirty Cache settings
With your Max/Min Dirty Cache settings, remember that disk speed will affect response time. An example of this is shown below.
Figure 5 - Disk speed and response time for Dirty Cache settings
Replication Threads - eDirectory Optimization Settings
In iMonitor, you can adjust the Agent Synchronization via the Agent Configuration option.
Figure 6 - Agent Synchronization
By using the ndsconfig get command, you can see the x The last four lines in the screen shot below tell you the following things:
- Thread Timeout (millisecs)
- Minimum Threads in Pool
- Minimum Threads in Pool at Startup
- Maximum Number of Threads in Pool
Figure 7 - NDSConfig Get
More on Worker Threads
The last parameter shown above, n4u.server.max-threads, lists the maximum number of threads that will be started by the eDirectory server. This is the number of concurrent operations that can be done within the eDirectory server (the default is 64).
For LDAP, each eDirectory Worker Thread can handle up to 256 concurrent connections. Therefore, with 64 LDAP Worker Threads, eDirectory can handle up to 16,384 concurrent LDAP connections. You can type "ndstrace -c threads" to see how many active threads are running.
The n4u.server.idle-threads parameter lists the maximum number of idle threads that are allowed in the eDirectory server (the default is 8). This parameter should be set to a value that can handle the average concurrent connection load your system will have. By default, eDirectory is set to receive 2,048 concurrent LDAP connections.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com