This article is Part 3 of the “Oracle Internet Directory Scaling” series.
The previous entry, Part 2: Effective Implementation Strategies for Enterprises (Korean), covers effective implementation strategies to scale Oracle Internet Directory (OID) for enterprise success. If you haven’t read it yet, be sure to check it out first.
Separate the LDAP server and database path from work executed by WebLogic applications before diagnosing OID-related latency. WebLogic threads and JVM options govern work in that JVM; they do not directly control every OID LDAP operation.
This article separates scheduling constraints from JVM memory and GC settings. The financial-service figures, including 50,000 users and a 2.3-second average, are claims retained from the original article. The underlying load tests and change records have not been verified.
WebLogic Configuration: The System's Command Center
Thread Pool Management: Your System's Workforce
The original example cites 50,000 users and up to 15,000 concurrent authentication requests. Users, pending requests and executing threads are distinct measures. The XML below is an unvalidated illustration, not a verified deployment descriptor for your WebLogic version. Do not apply it as written.
<!-- config.xml, server level: self-tuning thread pool bounds (ServerMBean) -->
<server>
<name>wls_ods1</name>
<self-tuning-thread-pool-size-min>20</self-tuning-thread-pool-size-min>
<self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>
</server>The original article reports a 2.3-second average and timeouts during Asian market hours. Correlate queue waits, thread state and downstream latency before attributing a cause. The proposed XML changes remain unvalidated; confirm the descriptor location and schema before use.
The following changes are illustrative and have not been validated against the installed schema.
<!-- config.xml, server level (example values) -->
<server>
<name>wls_ods1</name>
<self-tuning-thread-pool-size-min>50</self-tuning-thread-pool-size-min>
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max> <!-- 400 is the default -->
</server>Distinguish server thread-pool sizing from Work Manager constraints. Similar names do not make them interchangeable.
Understanding Minimum Threads (50)
A min-threads-constraint governs minimum thread allocation for affected work. It does not pre-create a dedicated pool of 50 threads at startup or guarantee zero waiting time. It is distinct from the server pool minimum.
<min-threads-constraint>50</min-threads-constraint>
The original estimate of 30 baseline threads and a value of 50 lacks verified measurements. Check pending work and downstream dependencies; a minimum constraint is not spare capacity reserved at startup.
Maximum Threads (400)
A max-threads-constraint limits concurrent executing threads for the work sharing that constraint. The illustrated value 400 is neither proof of authentication capacity nor an interchangeable setting for the server-wide pool maximum.
<max-threads-constraint>400</max-threads-constraint>
Review these observations together when evaluating thread counts:
- CPU demand and runnable versus waiting work
- Configured stacks and total process memory, including native memory
- Downstream DB/LDAP pool limits and latency
Neither 25–50 threads per core nor 512KB–1MB per thread is a universal sizing rule. The original choice of 400 needs its load-test evidence.
Queue Size and Stuck Thread Detection
<!-- A limit on queued requests is a Work Manager capacity constraint -->
<work-manager>
<name>OIDWorkManager</name>
<capacity>
<name>OID-Capacity</name>
<count>500</count>
</capacity>
</work-manager>WebLogic has no thread-pool or queue-size element. The server-wide self-tuning thread pool is bounded by SelfTuningThreadPoolSizeMin/Max (Max defaults to 400), and a limit on queued requests is a Work Manager capacity constraint (default -1, no limit). StuckThreadMaxTime is a server setting that already defaults to 600 seconds and is deprecated in 12.2.1.4 in favor of MaxStuckThreadTime on the server failure trigger; it is a diagnostic threshold and does not guarantee completion or recovery. Longer queues can increase memory demand and waiting time.
Impact of Thread Pool Optimization
Higher thread counts and unlimited waiting are not evidence of improvement. Compare completion rate, latency distribution, errors and resource use under equivalent load.
Work Manager Configuration
Work Managers apply scheduling guidelines and constraints to WebLogic application work. Identify the actual target, dispatch policy and downstream limits before prioritizing latency-sensitive authentication. The original XML below has not been validated as deployable configuration.
<!-- One request class per Work Manager: use two Work Managers for two priorities -->
<work-manager>
<name>OID-Critical-WM</name>
<fair-share-request-class>
<name>Critical-Ops</name>
<fair-share>80</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>Critical-Min</name>
<count>25</count>
</min-threads-constraint>
</work-manager>
<work-manager>
<name>OID-Routine-WM</name>
<fair-share-request-class>
<name>Routine-Ops</name>
<fair-share>20</fair-share>
</fair-share-request-class>
<max-threads-constraint>
<name>OID-Max</name>
<count>400</count>
</max-threads-constraint>
</work-manager>Understanding Work Manager Configuration
Minimum and maximum constraints and fair share serve different purposes. Names and counts in this example do not establish a dedicated pool or an SLA.
<min-threads-constraint>
<name>Critical-Min</name>
<count>25</count>
</min-threads-constraint>A minimum constraint of 25 does not reserve 25 dedicated threads at startup. It affects scheduling of pending work but cannot remove downstream latency or resource exhaustion. A min-threads-constraint has only a name and a count; pool-name belongs to a max-threads-constraint sized from a connection pool. The following fair-share values are relative weights (default 50), and each request class goes in its own Work Manager.
<fair-share-request-class> <name>Critical-Ops</name> <fair-share>80</fair-share> </fair-share-request-class> <fair-share-request-class> <name>Routine-Ops</name> <fair-share>20</fair-share> </fair-share-request-class>
80 and 20 are not fixed CPU or memory percentages. Under sufficient competing demand they guide relative thread-use time, without guaranteeing per-request latency or a constant observed ratio.
JVM Optimization: Memory Management Mastery
Separate heap, class metadata, stacks and other native memory when examining a JVM, and keep GC logs, versions and workload records for any change you evaluate.
Understanding JVM Memory Architecture
Basic generational roles
- Eden normally receives new allocations; collector-specific paths, including large objects, can differ.
- Survivor areas hold surviving objects; movement and promotion depend on age and collector policy.
- Old regions hold long-lived or promoted objects. Longevity does not prove business value or the absence of leaks.
With G1, generations are sets of regions rather than simply fixed contiguous partitions. The diagram is conceptual, not a measurement of the installed JVM.
Initial Situation Assessment
This is the original starting JVM example. Check option support and the JVM actually launched before applying it.
# Initial memory settings JAVA_OPTIONS="-Xms2048m -Xmx4096m" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:+UseParallelGC"
Initial and maximum heap sizes alone do not establish the cause of GC delays. Confirm pause times and their cause (for example fragmentation or heap resizing) from GC logs.
Memory Configuration: Building the Right Spaces
The following is the original proposed option set, not a validated recommendation. Check the supported WebLogic/JDK combination, memory budget and workload tests first.
# Optimized memory settings JAVA_OPTIONS="${JAVA_OPTIONS} -Xms6144m -Xmx6144m" # G1GC configuration JAVA_OPTIONS="${JAVA_OPTIONS} -XX:+UseG1GC" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MaxGCPauseMillis=200" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:ParallelGCThreads=8" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:ConcGCThreads=2" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:InitiatingHeapOccupancyPercent=45" # Metaspace configuration JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MetaspaceSize=256m" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MaxMetaspaceSize=512m"
Separate each option’s role from the conditions needed to use its example value.
Heap Size Configuration
JAVA_OPTIONS="${JAVA_OPTIONS} -Xms6144m -Xmx6144m"
Setting both -Xms and -Xmx to 6GB can limit heap-size changes. It does not make 6GB a universal recommendation or establish that latency has been fixed. Budget for the OS, stacks, Metaspace and other memory outside the heap.
Garbage Collection Strategy
JAVA_OPTIONS="${JAVA_OPTIONS} -XX:+UseG1GC" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MaxGCPauseMillis=200" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:ParallelGCThreads=8"
G1 manages the heap in regions. MaxGCPauseMillis=200 is a pause-time goal, not a guaranteed ceiling. ParallelGCThreads=8 configures parallel GC work. Confirm supported JDK options and evaluate CPU demand and GC logs before tuning them.
Memory Management Triggers
JAVA_OPTIONS="${JAVA_OPTIONS} -XX:InitiatingHeapOccupancyPercent=45" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:ConcGCThreads=2"
Fusion Middleware 12.2.1.4 runs on JDK 8. In JDK 8’s G1, InitiatingHeapOccupancyPercent is the occupancy of the entire Java heap at which a concurrent marking cycle starts (default 45). Adaptive IHOP, which adjusts that threshold from observed behavior, arrived in JDK 9. ConcGCThreads controls concurrent GC work; stop-the-world phases still exist.
Metaspace Configuration
JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MetaspaceSize=256m" JAVA_OPTIONS="${JAVA_OPTIONS} -XX:MaxMetaspaceSize=512m"
Metaspace holds class metadata in native memory. MetaspaceSize=256m sets an initial metadata threshold associated with GC, not a preallocated 256MB initial area. MaxMetaspaceSize=512m sets a size limit. Check supported-JDK definitions, defaults and the risk of reaching that limit.
Memory Management Triggers Deep Dive
Evaluate marking thresholds and concurrent GC threads separately, then check their actual effects in the logs.
Check which JDK your Fusion Middleware release is certified on before relying on InitiatingHeapOccupancyPercent=45.
JAVA_OPTIONS="${JAVA_OPTIONS} -XX:InitiatingHeapOccupancyPercent=45"
On JDK 8 the value is a fixed whole-heap threshold; on JDK 9 and later, adaptive IHOP adjusts it using observed marking duration and allocation rate. In either case, confirm the actual marking start in the GC logs. The next example specifies concurrent GC threads.
JAVA_OPTIONS="${JAVA_OPTIONS} -XX:ConcGCThreads=2"
ConcGCThreads=2 is an example value. Concurrent work can compete with application CPU, and some GC phases still pause the application. Compare pause times, marking progress and reclamation headroom after a change.
Measuring the Effect
Accept a tuning result only after comparing latency, completion rate, errors and resource pressure under equivalent conditions. Configuration values and user counts alone do not establish reliability.
Oracle Internet Directory Scaling Part 3: Summary and Key Takeaways
Review WebLogic scheduling and JVM memory/GC settings in their actual layer and supported version. The retained examples are not verified deployment configurations or performance guarantees.
Start with WebLogic queue waits, concurrent execution and downstream latency, then examine native memory and GC pause distributions. Judge each setting by measured results under the same load.
Monitor workload and latency continuously, and adjust the configuration using measured results.
Previous Article: Part 2: Effective Implementation Strategies for Enterprises (Korean)