# Benchmarking Native PHP: OPcache JIT vs. NGINX FastCGI Caching Under Concurrency When scaling backend infrastructure, common practice often leans toward scaling hardware vertically or introducing heavy microservice layers. However, when operating zero-dependency native PHP architectures, sub-second Time to First Byte (TTFB) and high throughput (Requests Per Second) can be achieved through server-level execution and caching strategies. We benchmarked three distinct backend configurations under synthetic concurrency load to measure raw execution performance, CPU utilization, and latency variations. **Test Environment & Methodology** All tests were executed on isolated Linux environments using wrk for HTTP benchmarking under 10k total requests with 100 concurrent connections. * Server: NGINX 1.24 + PHP 8.3-FPM. * Benchmarking Tool: wrk -c 100 -t 8 -d 30s. * Metrics Tracked: Avg Response Time (TTFB), Throughput (RPS), and Server Memory Overhead. **Configuration Profiles: 1.** Standard Vanilla PHP-FPM: Base state running standard PHP-FPM without bytecode persistence or output buffering. Standard execution requires disk reads and parsing on every incoming HTTP hit. **2\. Tuned OPcache + JIT Enabled:** Configured via php.ini to retain bytecode directly in memory, bypassing script compilation per request: Ini, TOML opcache.enable=1 `opcache.memory_consumption=256` `opcache.max_accelerated_files=20000` `opcache.validate_timestamps=0` `opcache.revalidate_freq=0` `opcache.jit=tracing` `opcache.jit_buffer_size=128M` **3\. NGINX FastCGI Response Caching:** Bypassing PHP-FPM entirely for warm static GET routes by serving compiled HTML outputs directly out of memory via NGINX: `fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PHP_CACHE:100m max_size=1g inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri";` `server { location ~ .php$ { fastcgi_cache PHP_CACHE; fastcgi_cache_valid 200 60m; fastcgi_cache_use_stale error timeout updating; add_header X-Cache-Status $upstream_cache_status; # Standard FastCGI directives... } }` ### **Benchmark Metrics & Results Architecture**

Architecture Profile

Requests / Sec (RPS)

Avg Latency (TTFB)

CPU Load

Vanilla PHP-FPM

~180 RPS

85.4 ms

High (100% Core Utilization)

PHP + OPcache JIT

~1,250 RPS

12.1 ms

Moderate

PHP + NGINX FastCGI Cache

~8,600+ RPS

1.6 ms

Extremely Low (< 5%)

**Key Takeaways:** * **OPcache Eliminates I/O Bottlenecks:** Turning off `opcache.validate_timestamps` in production ensures PHP never accesses disk mtime attributes during execution loops.JIT for * **Computational Workloads:** JIT offers significant performance gains for heavy CPU loops or mathematical evaluations inside PHP.FastCGI * **FastCGI Caching for Peak Scalability:** For read-heavy web endpoints, moving the caching boundary to NGINX avoids invoking the PHP-FPM worker pool entirely, yielding near-static file delivery speeds. Originally published and detailed on the [Phase 1 Pixels Engineering Hub.](https://phase1pixels.ng/blog/php-opcache-jit-vs-nginx-fastcgi-cache.php)