Performance Stress Testing and Optimization for a Nuxt + Vue SSR Web Application

1. Why Conduct Stress Testing? Amazon research shows that every 100 ms latency loss reduces transaction volume by 1 %, highlighting the business impact of performance testing. The goal is to raise single‑machine QPS from 300 to 600, effectively doubling concurrency.

2. What Is Pressure Testing? Pressure testing (a type of performance test) continuously applies load to a system to discover its maximum capacity and identify bottlenecks. Core metrics include TPS, QPS, response time, CPU and memory utilization.

3. Testing Tool – wrk The article uses wrk , an HTTP benchmarking tool that leverages multi‑core CPUs, epoll/kqueue I/O, and multithreaded event‑driven architecture. Installation steps are illustrated with screenshots.

4. wrk Parameters

-c: number of HTTP connections (connections per thread = connections/threads)

-d: duration (e.g., 3s, 3m, 3h)

-t: total thread count

-s: script (Lua optional)

-H: additional HTTP header (e.g., User-Agent: iphone)

-latency: output detailed latency statistics

-timeout: request timeout

5. Stress‑Test Practice

Initial baseline exploration revealed a current QPS of 300 on a 4C8G machine. The target was to reach 600 QPS without adding machines. Preparations included building a replica environment, selecting wrk, and defining test scripts.

Baseline tests using multiple machines showed CPU saturation (~120 %) and QPS values exceeding the target, but inconsistencies (redirects, environment differences) required adjustments. After aligning the replica environment (4C8G) and controlling CPU usage around 100 %, reliable results were obtained (e.g., server‑side QPS ≈ 337, local wrk QPS ≈ 1120, later refined to ~600 after parameter tuning).

6. Bottleneck Analysis & Optimization

The optimization workflow consists of four stages:

Preparation: Roughly locate bottlenecks by commenting out suspect modules; Vue‑Router identified as a major limiter.

Analysis: Use node‑clinic flame graphs to pinpoint CPU‑intensive code paths.

Tuning: Replace auto‑generated routes with custom routes, enable server‑side rendering, split global components/styles, and remove unnecessary server middleware in nuxt.config.js .

Verification: Re‑run stress tests to compare metrics against the baseline; iterate if targets are not met.

7. Iterative Release & Future Plans

Once performance goals are met, the changes are merged and deployed. Ongoing monitoring ensures the system remains within expected thresholds, and post‑release testing validates that improvements persist.

8. Reflections

Select appropriate performance tools for efficient optimization.

Control variables during testing; change one factor at a time.

Document test results, bottlenecks, and remediation plans for future cycles.

Performance tuning is a continuous, iterative process.