https://github.com/aleixnguyen-vn/docker-wordpress-performance
WordPress Docker stack serving 5,000 users at 187ms on a 1GB VPS with Redis & Caddy.
https://github.com/aleixnguyen-vn/docker-wordpress-performance
caddy case-study docker docker-compose infrastructure nginx performance-optimization php-fpm redis vps vultr wordpress
Last synced: about 1 month ago
JSON representation
WordPress Docker stack serving 5,000 users at 187ms on a 1GB VPS with Redis & Caddy.
- Host: GitHub
- URL: https://github.com/aleixnguyen-vn/docker-wordpress-performance
- Owner: aleixnguyen-vn
- License: gpl-3.0
- Created: 2025-06-29T03:57:19.000Z (4 months ago)
- Default Branch: main
- Last Pushed: 2025-08-07T02:36:05.000Z (2 months ago)
- Last Synced: 2025-08-07T04:22:57.400Z (2 months ago)
- Topics: caddy, case-study, docker, docker-compose, infrastructure, nginx, performance-optimization, php-fpm, redis, vps, vultr, wordpress
- Language: PHP
- Homepage:
- Size: 1.29 MB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README







# π [CASE STUDY] WordPress on Docker: 5000 Client Benchmark on 1GB RAM VPS
> **"Optimizing WordPress at this level isnβt about plugins β itβs about removing bottlenecks one by one."**
> β οΈ Disclaimer: This repo focuses solely on the technical side β site architecture, deployment, and performance tuning skills.
---
## 1. π Objectives
- Run WordPress with Docker on a basic VPS (1vCPU, 1GB RAM)
- Serve 5000 concurrent clients/minute
- Achieve 189ms average response time
- Use only free or open-source stack (Docker, Caddy, Redis, MariaDB)---
## 2. βοΈ Stack Overview
- **VPS**: Vultr 6$ VPS (1vCPU, 1GB RAM, 25GB SSD NVMe)
- **OS:** Ubuntu 22.04 LTS
- **Web Server:** NGINX (behind Caddy for HTTPS)
- **CMS:** WordPress (php8.2-fpm)
- **DB:** MariaDB 10.5
- **Cache:** Redis (Object Cache)
- **SSL Proxy:** Caddy (reverse proxy + HTTP/3)
- **CDN:** Cloudflare (free plan)---
## 3. πͺ Key Optimizations
### 3.1 PHP-FPM Pool (wp-app)
```ini
pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500 ; auto recycle to avoid memory leak; increased php execution timeout
request_terminate_timeout = 30s
```### 3.2 OPCache
```ini
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0 ; if dont require hot reload file
opcache.revalidate_freq=60
```### 3.3 Redis Configuration
```ini
maxmemory 256mb
maxmemory-policy allkeys-lru
```- Redis as object cache for WordPress
- Hit rate: **99.93%**
- **No manual preload yet**, cache populated purely through real traffic### 3.4 NGINX Performance
```nginx
gzip on;
gzip_disable "msie6";gzip_vary on;
gzip_proxied any;
gzip_comp_level 5; # 1 - 9(5 for best performance)
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;gzip_types
text/plain
text/css
application/json
application/javascript
application/x-javascript
text/xml
application/xml
application/xml+rss
image/svg+xml;
```### 3.5 Caddy for SSL
```text
example.com {
reverse_proxy nginx:80 {
header_up X-Forwarded-Proto https
}encode gzip
@static {
path_regexp \.(jpg|jpeg|png|gif|ico|css|js|woff2?|ttf|svg)$
}header @static {
Cache-Control "public, max-age=31536000"
Expires "Sun, 31 Dec 2037 23:55:55 GMT"
}
}
```---
## 4. π Benchmark Results (Loader.io)
### Scenario:
- 5000 clients over 1 minute
- All requests to homepage (cached via Redis)| Metric | Value |
| ----------------- | ------------------------- |
| Avg Response Time | **189ms** |
| Redis Hit Rate | **99.93%** |
| Success Rate | **100%** |
| Max Latency | 486ms |
| RAM Usage (peak) | **\~451MB** |
| CPU | 2-6% |
| Errors / Timeouts | **0** |> π Even at 5000 users/minute, no Redis or MySQL bottlenecks were observed. Cache was warmed purely by live traffic.
---
## 5. π Summary
- Dockerized WordPress stack on 1vCPU/1GB RAM VPS
- No paid services: all open-source or free-tier
- Redis cache hit 241,595 / 179 β **99.93%** hit rate
- Caddy offloaded SSL + HTTP/3
- Cloudflare added as CDN layer (compression + edge cache)### Result:
> π **5000 concurrent users** served in 1 minute at **187ms average**, no crash, no errors. RAM used: **\~431MB**.
---
## 6. πΌ Some screenshots
Below are key screenshots capturing performance results and system metrics during the tests.
### πΉ 1. Loader.io Benchmark β 5000 Users,
#### π§ͺ Scene 1 β Warm cache, optimal performance

>**Final round**:
5,000 concurrent users Β· 187ms avg Β· 0% errors Β· 100% valid redirects
Max latency only 391ms β demonstrates steady-state performance under full load.#### π§ Scene 2 β Cold start (post page)

>Real-world uncached access: 198ms avg, 0% errors
Shows how the stack handles cache-warming and first-hit scenarios with zero degradation.---
### πΉ 2. 93 Google Lighthouse Score

>Score: 93/100 (Desktop)
Minimal layout shift, optimized loading.
cf-cache-status: HIT, HTML gzip, no render-blocking JS.> β οΈ Note: idk why Pingdom score stuck at **87/100** despite full gzip and cache header tuning β likely due to CDN location and test heuristics.
---
### πΉ 3. Redis Hit Rate

*241,595 cache hits vs. 179 misses β 99.93% hit rate without preload.*---
### πΉ 4. Docker Stats + `htop` During Load Test

>RAM usage: ~431MB peak
All services stayed under control, including PHP-FPM, Redis, MariaDB
Swap barely touched, CPU stable at 2β6%---
### πΉ 5. Chrome DevTools: Network Tab

>β cf-cache-status: HIT
β gzip enabled
β HTTP/3 from Caddy
TTFB under 200ms, total load <2s across 67 assets.---
### πΉ 6. Folder Structure / Project Layout

*Modular Docker-based layout with isolated services and shared volumes.*### π₯ 7. Server Specs β Vultr 1GB VPS

> Benchmark environment: Vultr 1vCPU / 1GB RAM VPS (Frankfurt). Stack deployed on Ubuntu 22.04 with Docker. Current cost: $0.07.*---
_For more screenshots of alternative configs and test iterations, browse the full `/screenshots` folder in the repository._
## 7. π Future Improvements
- Add FastCGI Cache (NGINX-level full page caching)
- Integrate GitHub Actions to trigger Redis preload after deploy
- Explore ESI + Edge Caching (via QUIC.cloud or Cloudflare Workers)
- Auto-monitor Redis hit rate and auto-flush if fallback detected---
## 8. πΌ Repository & Source Code
> [https://github.com/aleixnguyen-vn/docker-wordpress-performance](https://github.com/aleixnguyen-vn/docker-wordpress-performance)
---
> β±οΈ I picked up Docker at 2PM. This stack was live β and benchmarking β before midnight.
> π "You don't need a bigger server. You need better config."