Backend Development 8 min read

JSF 1.7.6 Preheat Strategy Practice and Performance Test Report

This article presents a detailed practice report on the JSF 1.7.6 preheat strategy applied to JD's VOP platform, describing the background, test scenarios, deployment process, monitoring results with and without preheat, and concluding that dynamic preheat significantly reduces performance spikes during service rollout.

JD Tech
JD Tech
JD Tech
JSF 1.7.6 Preheat Strategy Practice and Performance Test Report

The enterprise front‑end includes most external business systems, and JD's VOP platform provides an API for internal procurement malls, pushing product SKUs directly to customers' intranet where procurement staff can order; the VOP mode keeps customer data isolated for security.

With thousands of SaaS malls using VOP, the API must handle high concurrency, availability, and reliability. During releases, even minimal traffic fluctuations can trigger alerts, potentially leading to customer complaints.

Background : JSF 1.7.6 introduced a dynamic preheat strategy. This article reports a practical test of that feature.

Scenarios :

Scenario 1 – External service: during the startup phase, some interfaces experience many 5xx timeout errors.

Scenario 2 – Provider service: after machine startup, JSF interfaces also encounter timeout requests.

Both scenarios cause stability alerts (TP99/availability). Monitoring shows the affected interfaces were under deployment.

Preheat Management Practice : MCube checks template cache, fetches the latest template if needed, loads it into a view‑tree, resolves expressions and custom events, binds them, and finally renders the page.

Test Flow : A load generator simulates calls to the target interface, stabilizes traffic, then performs a staged rollout with 50% of machines.

Without Preheat :

Monitoring screenshots (provider and consumer) show performance degradation during rollout. The release period (15:40‑15:44) with 50% traffic caused noticeable latency spikes.

With Preheat :

Preheat dynamically adjusts traffic weight, allowing a small amount of traffic to warm up new nodes. Configuration changed from weight 10, period 30 000 ms to weight 1, period 60 000 ms to improve effect.

During the preheated rollout (17:36‑17:40) the same 50% traffic resulted in minimal latency (16 ms) and a 2.8‑15× reduction in performance impact on the two machines.

Conclusion : The instant high TP after provider cold‑start caused request loss, which can be mitigated by the automatic preheat mechanism. Preheat significantly smooths traffic during deployment, reducing alerts and improving user experience.

Key interfaces:

Consumer HTTP: https://bizapi.jd.com/api/area/getTown

Provider JSF: com.jd.ka.vop.soa.address.sdk.provider.QueryAddressOpenProvider#queryJdAreaIdList

backendperformance testingAPIJSFpreheatVOP
JD Tech
Written by

JD Tech

Official JD technology sharing platform. All the cutting‑edge JD tech, innovative insights, and open‑source solutions you’re looking for, all in one place.

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.