Backend Development 5 min read

Interface Performance Optimization Journey: Using Pfinder and JSF Asynchronous Calls

The article details a performance optimization case where interface latency was diagnosed with Pfinder and UMP, revealing excessive RPC calls and database queries, and then improved by replacing inefficient list operations with Set-based logic and introducing JSF asynchronous calls, cutting response times from seconds to milliseconds.

JD Tech Talk
JD Tech Talk
JD Tech Talk
Interface Performance Optimization Journey: Using Pfinder and JSF Asynchronous Calls

The article begins by describing common interface response‑time issues in project development and the need for systematic optimization covering code, database, caching, and asynchronous processing.

In the diagnosis phase, UMP shows a maximum latency of 10 s, a T99 of 1000 ms, and declining availability. Pfinder diagnostics reveal three major bottlenecks: (1) looping RPC calls 120 times consuming 1441 ms, (2) a database query taking 286 ms, and (3) an unknown operation exceeding 2000 ms.

To address the Pfinder tracing gap, the authors integrate the Pfinder SDK via a Maven dependency:

<dependency> <groupId>com.jd.pfinder</groupId> <artifactId>pfinder-profiler-sdk</artifactId> <version>1.2.2-FINAL</version> </dependency>

They apply the @PFTracing annotation to methods and manually enhance full‑chain tracing, which exposes the inefficient list‑filtering code:

// original inefficient code List<String> repeatResult = new ArrayList<>(); List<String> showPackages = new ArrayList<>(); for (String w : waveInfos) { if (sendDPackageCodes.contains(w)) { repeatResult.add(w); } else { showPackages.add(w); } }

Analysis shows waveInfos (>3000) and sendDPackageCodes (>7000) cause the O(n²) delay. Replacing the list lookup with a Set reduces the operation from ~2000 ms to 6 ms.

The second major issue is the synchronous RPC batch call (120 invocations ≈1400 ms). The solution uses JSF asynchronous invocation:

1. Inject an async‑capable bean alongside the existing sync bean.

2. Declare a JSF consumer with async="true" (note: same interface alias limited to 3).

<jsf:consumer id="xxx" interface="xxx" protocol="jsf" alias="xx" timeout="xxx" retries="0" check="false"> <jsf:method name="方法名称" async="true" /> </jsf:consumer>

3. The async proxy returns a CompletableFuture via RpcContext.getContext().asyncCall(() -> xxxxAsyncApi.method()); .

4. Callers retrieve the result with a timeout helper:

public <T> T getResultDefaultTimeOut(CompletableFuture<T> future) { try { return future.get(10, TimeUnit.SECONDS); } catch (InterruptedException | ExecutionException | TimeoutException e) { throw new RuntimeException(e); } }

Optimization results: RPC latency drops from ~1400 ms to ~200 ms.

The final section shows before/after latency charts, confirming that combined optimizations (Set‑based filtering and JSF async) reduce overall interface response from several seconds to under a few hundred milliseconds, greatly improving throughput and user experience.

Conclusion: Interface performance optimization requires multi‑dimensional diagnosis (UMP, Pfinder), targeted code improvements (algorithm complexity reduction), and asynchronous RPC patterns to achieve substantial latency gains.

Performance OptimizationRPCJava backendJSF asynchronousPfinderSet optimization
JD Tech Talk
Written by

JD Tech Talk

Official JD Tech public account delivering best practices and technology innovation.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.