How To Triage OAS Sign-In and Dashboard Slowness After an OCI Migration

Right after a migration, when users say “sign-in is slow and dashboards are slow,” the first instinct is often to blame server sizing (CPU/memory/storage). Resource constraints can absolutely be the root cause in some cases, but when the perceived latency increases immediately after moving to OCI, the usual culprits are frequently configuration differences across: the traffic path (Load Balancer/WAF/OHS), the authentication path (AD/LDAP), and the DB/network path. These differences can dominate real-world user experience even when compute resources look sufficient.

This post does not try to provide a single “correct answer.” The goal is to help you move faster through the most time-consuming part: classification and initial analysis. If you split the symptom into sign-in latency and dashboard loading latency, and collect the minimum evidence needed for each track, your investigation becomes far more efficient—especially in environments where backend bypass tests are not feasible.

1) Pattern framing: the “three-sentence” scope reduction

Most real incidents start with a one-liner: “Login is slow” or “Dashboards are slow.” Before increasing log levels, restarting services, or blaming infrastructure, fill these three statements first—this is usually the highest ROI step.

• When: When did it become slow? (immediately after OCI migration vs after a later change)
• Who: Which users are affected? (all users vs a subset vs a specific account type)
• Where: Which phase is slow? (sign-in vs dashboard load vs both)

Once these are answered, the priority order becomes natural. For example, if “all users are slow at sign-in,” authentication/session initialization and the Front Door path move to the top. If sign-in is normal but a specific dashboard is slow, you should pivot to the query/DB track early.

2) Triage when backend bypass is not allowed

The cleanest test is “bypass LB/WAF and repeat the same scenario.” In many environments, security policies do not allow that. That does not mean you cannot triage. If bypass is not possible, the Front Door configuration (LB/WAF/OHS) becomes an even stronger candidate and deserves early attention.

In non-bypass environments, reduce variables by walking these three axes:

1. Front Door axis: SSL termination point, timeouts, keep-alive, header forwarding, sticky sessions
2. Authentication/Middleware axis: provider chain behavior, LDAP/AD connection and search latency
3. Query/DB axis: isolate Physical SQL and validate with execution plans and DB-side waits

Caption: A simplified OCI traffic path (e.g., Internet → OCI LB/WAF → OHS → OAS/WebLogic). Keeping this diagram aligned to your real deployment helps focus discussions on where time is being spent.

3) What to collect: preserve “evidence” with the smallest useful set

3-1. Pin the patch level (mandatory baseline)

Performance investigations often get derailed because multiple “similar-looking” issues overlap. Right after a migration, software level (patch bundle/PSU) and configuration (auth/network/proxy) often change at the same time. Your first step should be to capture the OPatch inventory to lock the baseline.

cd $ORACLE_HOME/OPatch
./opatch version
./opatch lsinventory -detail > /tmp/opatch_lsinventory_detail_$(hostname)_$(date +%F).txt

This output is not “just for reference.” It is your audit trail. If performance improves after you change timeouts or provider settings, you still need to separate “config effect” vs “patch effect.” Baseline data makes that possible.

3-2. Front Door (LB/WAF/OHS): commonly missed tuning points

One of the most common OCI migration deltas is where TLS is terminated. If TLS terminates at the LB, backend traffic might be HTTP. If you keep end-to-end TLS, OHS/WLS sees TLS directly. There is no universal “right” choice, but a change here often affects: connection reuse (keep-alive), idle/backend timeouts, and header processing—all of which can dominate perceived latency.

• Timeout alignment: Confirm how client/backend/idle timeouts are set and aligned across LB/WAF/OHS.
• Keep-Alive: If connections are recreated per request, both sign-in and dashboards can become noticeably slower.
• Sticky session: Check whether post-login requests are spread across nodes causing repeated session/auth work.
• Proxy headers: Validate Host and X-Forwarded-* behavior matches what OHS/WLS expects in your design.

3-3. Authentication (AD/LDAP): confirm first, do not conclude from a single dump

If sign-in time grows significantly, you should check whether user/group lookups are delayed. However, seeing LDAP-related threads in a thread dump does not prove LDAP is the root cause. LDAP threads can be “normally waiting,” while the real bottleneck is elsewhere (Front Door, DB, internal cache).

If LDAP threads repeatedly show the stack pattern below, they may be waiting on network responses. Note that Java thread state may appear RUNNABLE even while the thread is effectively blocked in a native socket read (e.g., socketRead0). The critical proof is whether this wait blocks the request-handling (business) threads serving your login.

- java.net.SocketInputStream.socketRead0
- java.io.BufferedInputStream.read / fill
- netscape.ldap.ber.stream.BERElement.getElement
- netscape.ldap.LDAPConnThread.run

PID=<bi_server1_pid>
jcmd $PID Thread.print > /tmp/bi_server1_td_1.txt
sleep 10
jcmd $PID Thread.print > /tmp/bi_server1_td_2.txt
sleep 10
jcmd $PID Thread.print > /tmp/bi_server1_td_3.txt

4) Slow dashboards: when to pivot to the Query/DB track

If sign-in is normal but dashboard loading is slow, pivot away from “authentication” and focus on “query/DB.” A common mistake is to keep hunting in WebLogic/Front Door while the actual bottleneck is an expensive Physical SQL query. Ultimately, dashboard delay must be narrowed to: which Physical SQL runs and how long it takes.

Practically, the flow is:

1. Reproduce the slowness and identify which queries run during the slow window.
2. Validate the Physical SQL on the DB side: execution plan, waits, index usage, and resource consumption.
3. If it is slow only in OCI, compare DB placement, network path, and session/environment differences with On-Prem.

5) Wrap-up: a minimal checklist for higher-quality triage