Performance Analysis Report

Performance Analysis Report: school.pesonaedu.id Load Test

Date: June 8, 2026
Load Test Target: https://school.pesonaedu.id
Peak Load: 500 Virtual Users (VUs)

This report provides a comparative performance analysis of four load test runs executed from different environments:

1. Run 1 (Farly’s Environment - results.csv): Initial client-side test (unstable local connection).
2. Run 2 (Herman’s Environment - results_herman.csv): Client-side test (high-performance local connection).
3. Run 3 (Private Server - results_server.json): Server-local backend test (zero public internet latency).
4. Run 4 (Anas’s Environment - results_anas.json): Client-side test (stable high-speed connection).

---

1. Side-by-Side Performance Comparison

Metric	Run 1 (Farly - Initial)	Run 2 (Herman - New)	Run 3 (Private Server)	Run 4 (Anas - Added)	Diagnostics / Observations
Total Requests	52,714	89,312	67,506	80,252	Run 2 pushed the highest throughput, closely followed by Run 4.
Failed Requests	356	2	0	0	0% failures in Runs 3 and 4; server is highly stable under sustained load.
Success Rate	99.325%	99.998%	100.00%	100.00%	Web and database engines do not crash at 500 VUs.
Peak VUs	500	500	500	500	Consistent testing scale across all runs.
Min Latency	29.81 ms	0.00 ms	90.35 ms	7.29 ms	Run 4 shows extremely fast initial connection speeds.
Average Latency	3,581.51 ms	1,693.85 ms	2,572.51 ms	1,999.79 ms	Runs 2 and 4 had the fastest average speed.
Median ($P_{50}$)	2,775.11 ms	119.69 ms	3,303.47 ms	1,635.06 ms	Run 2 served half of its requests extremely fast.
90th Percentile ($P_{90}$)	4,893.62 ms	3,986.01 ms	3,951.62 ms	4,424.76 ms	All runs hover around ~3.9s to 4.4s at the 90% mark.
95th Percentile ($P_{95}$)	5,591.73 ms	4,852.24 ms	4,099.49 ms	4,680.73 ms	Run 3 remains the most stable at the 95th percentile.
99th Percentile ($P_{99}$)	39,009.05 ms	29,444.21 ms	4,300.69 ms	5,063.78 ms	🚀 Runs 3 and 4 show no massive long-tail timeouts at 99%.
Maximum Latency	56,769.38 ms	38,971.94 ms	4,775.29 ms	26,199.40 ms	Run 4 shows some tail latency congestion (26.20s) but no failures.

---

2. Key Insights from the Private Server & High-Performance Runs

A. Zero Failures & Perfect Server Availability

Runs 3 and 4 logged exactly 0 failures out of 67,506 and 80,252 requests, respectively.

• Insight: This confirms that the application and database servers did not crash under 500 concurrent users. The failures observed in Run 1 (356 errors) were entirely due to client-side network dropouts, public DNS issues, or TCP port limits.

B. Bounded Long-Tail Latency (No 30+ Second Timeouts)

In the early client-side runs, the maximum latency reached 56.7 seconds (Run 1) and 38.9 seconds (Run 2). However, in Run 3 (Server-local), the absolute slowest request took only 4.78 seconds, and in Run 4 (Anas) the 99th percentile ($P_{99}$) was tightly bounded at 5.06 seconds.

• Insight: The massive 30-50 second timeouts experienced by public testers were not caused by the web/db servers locking up. Instead, they were caused by connection queueing at the public internet gateway (e.g., load balancer backlogs, public gateway timeouts, or ISP packet drops under saturation).

C. Consistent Core Latency (Median 3.30s vs 1.64s)

In Run 3, the median latency was 3.30 seconds (higher than Run 2’s median of 120ms), and Run 4 recorded a median of 1.64 seconds.

• Insight: Run 3 processed the homepage redirect loop (303 to 200) strictly on the server’s backplane network, experiencing zero internet speed variation. This shows that the pure PHP-FPM execution time under peak CPU load takes a consistent 1.5 to 2.0 seconds per request stage. Run 4, run over a high-performance network, confirms that PHP-FPM execution dominates latency rather than network transit under heavy loads.

D. High Throughput with Stable Connectivity (Run 4)

Run 4 from Anas’s environment achieved 80,252 requests with exactly 0 failures and a 100.00% success rate.

• Insight: This confirms the findings of Run 3: under stable connection conditions, the web server is highly reliable and handles 500 VUs with zero crash rate. However, unlike the zero-latency private server run (which had a max latency of 4.78s), Run 4 hit a maximum latency of 26.20 seconds despite its 99th percentile being very low (5.06 seconds). This shows that while internet connectivity was generally excellent, transient public gateway queueing or public ISP latency spikes still occurred near the very end of the tail ($P_{99.9}$).

---

3. Conclusions & Final Optimization Roadmap

The server is highly stable and does not fail, but public users will experience long-tail page loads (up to 30-50s) under high concurrency due to gateway queueing and network overhead.

To optimize the system for 500 VUs:

1. Reduce Public Gateway Queueing: Ensure the public-facing proxy/load balancer (e.g., Nginx, Cloudflare) has high connection backlog limits and HTTP/2 keep-alive settings.
2. Optimize PHP-FPM Worker Pool: Increase the child process pool size on the server so PHP requests don’t queue locally while waiting for a processor thread.
3. Database Caching (Redis/Memcached): Implement an in-memory cache store to reduce the time PHP spends waiting on database queries.
4. CDN Caching: Route all static assets through a CDN to lower the load on the origin server.