Nginx เป็น web server ที่มีประสิทธิภาพสูงและใช้ resources น้อย แต่หากไม่ได้รับการปรับแต่งให้เหมาะสม มันก็อาจกลายเป็น bottleneck สำหรับแอปพลิเคชันของคุณ บนระบบ Cloud VPS ที่มี resources จำกัด การ tuning Nginx ให้เหมาะสมจึงมีความสำคัญอย่างยิ่ง บทความนี้จะอธิบายรายละเอียดเกี่ยวกับการปรับแต่ง Nginx ให้ได้ประสิทธิภาพสูงสุดตามแนวทางมืออาชีพ
เมื่อ Nginx ได้รับการ tuning อย่างถูกต้อง คุณจะสังเกตเห็นการลดลงของ CPU usage ลดเวลา response time และสามารถจัดการ concurrent connections ได้มากขึ้น ซึ่งส่งผลต่อประสบการณ์ผู้ใช้และอัตราการแปลง (conversion rate) ของเว็บไซต์ของคุณ
Worker Processes และ Worker Connections
หนึ่งในพารามิเตอร์ที่สำคัญที่สุดในการ tuning Nginx คือ worker_processes ซึ่งกำหนดจำนวนของ worker process ที่ Nginx จะสร้างขึ้น
ค่า worker_processes ที่เหมาะสมควรตั้งเท่ากับจำนวนของ CPU cores ที่มีอยู่บนระบบ คุณสามารถตั้งเป็น “auto” เพื่อให้ Nginx ตรวจจำนวน CPU cores โดยอัตโนมัติ
worker_processes auto;
worker_rlimit_nofile 100000;
พารามิเตอร์ worker_connections กำหนดจำนวนสูงสุดของ simultaneous connections ที่ worker process เดียวจะสามารถจัดการได้ ค่าทั่วไปคือ 1024 แต่สำหรับระบบ Cloud VPS ที่มีการจราจรสูง คุณอาจต้องเพิ่มค่านี้
events {
worker_connections 2048;
use epoll;
}
ค่ากำลังคำนวณได้จากสูตร: max_clients = worker_processes × worker_connections ดังนั้นหากคุณมี 4 CPU cores และตั้ง worker_connections เป็น 2048 คุณจะสามารถจัดการได้ถึง 8,192 concurrent connections
Event Model: Epoll/Kqueue
Event model ที่ Nginx ใช้มีความสำคัญต่อประสิทธิภาพ Linux systems ส่วนใหญ่ใช้ epoll ซึ่งมีประสิทธิภาพสูงกว่า select/poll อย่างมาก
events {
worker_connections 2048;
use epoll;
multi_accept on;
}
พารามิเตอร์ multi_accept ช่วยให้ worker process สามารถยอมรับ multiple connections ในครั้งเดียวได้ ซึ่งช่วยลดจำนวนของ context switches
Keepalive Timeout และ Keepalive Requests
Keepalive connection ช่วยให้ client สามารถใช้ connection เดียวกันสำหรับ multiple requests ได้ ซึ่งช่วยลดโครงสร้างพื้นฐานของ TCP connection
http {
keepalive_timeout 65;
keepalive_requests 100;
keepalive_disable msie6;
}
keepalive_timeout กำหนดระยะเวลาที่ connection จะยังคงเปิดอยู่หลังจาก request สำหรับระบบ Cloud VPS ที่มีความหนาแน่นของ connections สูง ค่า 30-65 วินาที ถือว่าเหมาะสม
keepalive_requests กำหนดจำนวนสูงสุดของ requests ที่สามารถส่งผ่าน keepalive connection เดียวได้ ค่า 100 ถือว่าสมดุลระหว่างประสิทธิภาพและการใช้ resources
TCP Nodelay และ TCP Nopush
พารามิเตอร์เหล่านี้เกี่ยวข้องกับการส่งข้อมูล TCP และการควบคุม Nagle’s algorithm
http {
tcp_nodelay on;
tcp_nopush on;
}
tcp_nodelay ปิดใช้งาน Nagle’s algorithm ซึ่งหมายความว่าข้อมูลจะถูกส่งทันทีแทนที่จะรอให้มีข้อมูลมากพอ ซึ่งช่วยลด latency
tcp_nopush ขอให้ OS ส่งส่วนหัว HTTP response และเนื้อหาแยกกัน ซึ่งช่วยอักษร fragmentation และลด overhead
Sendfile และ AIO
Sendfile เป็นวิธีที่มีประสิทธิภาพในการส่งไฟล์ static โดยข้ามช่องว่าง user space
http {
sendfile on;
sendfile_max_chunk 512k;
}
Async I/O (AIO) ช่วยให้ Nginx สามารถอ่านไฟล์ได้โดยไม่บล็อก worker process
http {
aio on;
aio_write on;
directio 5m;
}
directio กำหนดไฟล์ที่ใหญ่กว่า 5MB เพื่อใช้ direct I/O ซึ่งจะข้าม page cache
Buffer Tuning
Buffer size มีความสำคัญต่อการจัดการ requests ขนาดใหญ่และ responses
http {
client_body_buffer_size 128k;
client_max_body_size 10m;
client_header_buffer_size 1k;
large_client_header_buffers 4 16k;
proxy_buffer_size 4k;
proxy_buffers 8 4k;
proxy_busy_buffers_size 8k;
proxy_request_buffering off;
}
client_body_buffer_size ควรมากพอสำหรับ form submissions แต่ไม่ควรใหญ่เกินไป ซึ่งจะใช้ memory unnecessarily
proxy_buffers ช่วยให้ Nginx สามารถ buffer responses จากต้นน้ำ (upstream) ได้อย่างมีประสิทธิภาพ
Gzip Compression Optimization
Compression ช่วยลดขนาดของ responses ได้อย่างมาก แต่ต้องปรับแต่งให้เหมาะสมเพื่อไม่ให้เพิ่มโหลด CPU
http {
gzip on;
gzip_comp_level 5;
gzip_min_length 1000;
gzip_types text/plain text/css text/xml text/javascript
application/x-javascript application/xml+rss
application/javascript application/json;
gzip_vary on;
gzip_buffers 16 8k;
}
gzip_comp_level ที่ 5 ถือว่าสมดุลระหว่างขนาด compression และ CPU usage ค่า 1 นั้นเร็วกว่า แต่บีบอัดน้อย ค่า 9 นั้นบีบอัดมากกว่า แต่ช้ากว่า
gzip_min_length ป้องกันไม่ให้ compress ไฟล์ขนาดเล็ก เนื่องจากการ compress อาจเพิ่มขนาดได้
Open File Cache
Open file cache ช่วยให้ Nginx จำ file descriptors และสถานะไฟล์ได้ ซึ่งลดการเรียกระบบไฟล์
http {
open_file_cache max=10000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
max กำหนดจำนวนสูงสุดของไฟล์ที่จะ cache inactive กำหนดเวลาที่จะลบ entry ที่ไม่ได้ใช้
Connection Pooling และ Upstream Keepalive
หากคุณใช้ Nginx เป็น reverse proxy การกำหนด keepalive connections ไปยัง upstream servers ช่วยลด overhead
upstream backend {
server 192.168.1.1:8080;
server 192.168.1.2:8080;
keepalive 32;
keepalive_timeout 60s;
keepalive_requests 100;
}
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
keepalive 32 หมายความว่า Nginx จะ maintain 32 idle connections ไปยัง upstream servers
SSL Session Caching และ Tickets
SSL/TLS termination ที่ Nginx มักจะใช้ resources สำคัญ SSL session caching ช่วยลด handshake overhead
http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_buffer_size 4k;
}
server {
listen 443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
}
shared:SSL:10m หมายความว่า 10MB ของ SSL session cache ถูก share ในทุก worker processes
Static File Serving Optimization
การ serve static files อย่างมีประสิทธิภาพนั้นสำคัญมากสำหรับ web performance
server {
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ {
expires 365d;
add_header Cache-Control "public, immutable";
add_header X-Content-Type-Options "nosniff";
access_log off;
}
location ~* ^/assets/ {
expires 1y;
sendfile on;
tcp_nopush on;
}
}
การ set expires headers ที่นาน ช่วยให้ browsers cache static files และลด requests ไปยัง server
Microcaching Strategy
Microcaching เป็นเทคนิคที่ cache dynamic content เป็นเวลาสั้น ๆ (ไม่กี่วินาที) เพื่อลด load ต่อ backend
http {
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:10m
max_size=1g inactive=60m;
}
server {
location / {
proxy_cache microcache;
proxy_cache_valid 200 10s;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout invalid_header updating;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
}
}
proxy_cache_valid 200 10s หมายความว่า responses ที่ประสบความสำเร็จจะถูก cache 10 วินาที
Kernel Parameter Tuning (Sysctl)
การ tune kernel parameters บนระบบปฏิบัติการก็มีความสำคัญเท่ากับการ tune Nginx configuration
# /etc/sysctl.conf
# Increase system IP port range
net.ipv4.ip_local_port_range = 1024 65535
# Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
net.ipv4.tcp_max_tw_buckets = 1440000
# Increase TCP backlog
net.ipv4.tcp_max_syn_backlog = 3240000
net.core.somaxconn = 3240000
# Increase the number of incoming connections
net.core.netdev_max_backlog = 5000
# Increase the maximum amount of memory buffers
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# Increase the tcp-time-wait buckets pool size
net.ipv4.tcp_tw_reuse = 1
ค่าเหล่านี้จะช่วยให้ระบบจัดการ high-traffic loads ได้ดีขึ้น หลังจากแก้ไข /etc/sysctl.conf ให้รันคำสั่ง sysctl -p เพื่อ apply changes
Benchmarking Tools: ab, wrk, siege
เพื่อวัด impact ของการ tuning คุณต้องใช้ benchmarking tools
Apache Bench (ab) เป็น tool ที่ง่ายที่สุด:ab -n 10000 -c 100 http://example.com/
-n 10000 หมายความว่าส่ง 10,000 requests -c 100 หมายความว่า 100 concurrent connections
Wrk ให้ผลลัพธ์ที่ลึกซึ้งกว่า:wrk -t12 -c400 -d30s http://example.com/
-t12 ใช้ 12 threads -c400 เป็น 400 concurrent connections -d30s ทำการ test 30 วินาที
Siege มี features มากมาย:siege -c 100 -r 100 -b http://example.com/
Profiling และ Bottleneck Identification
ก่อนที่จะเริ่ม tuning ควรระบุ bottleneck ที่แท้จริง
ใช้ Nginx Stub Status:server {
listen 127.0.0.1:8080;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
เยี่ยม http://127.0.0.1:8080/nginx_status เพื่อดูสถานะของ Nginx
Monitor System Resources:# Check CPU usage
top -bn1 | grep Cpu
# Check Memory
free -h
# Check disk I/O
iostat -x 1
# Monitor Nginx processes
ps aux | grep nginx
Best Practices Checklist
- ตั้ง worker_processes เท่ากับจำนวน CPU cores หรือใช้ “auto”
- เพิ่ม worker_connections ให้เหมาะสมกับ traffic patterns
- เปิดใช้งาน sendfile, tcp_nodelay, และ tcp_nopush
- กำหนด keepalive connections ให้เหมาะสม
- ตั้งค่า gzip compression ที่สมดุล
- ใช้ open_file_cache เพื่อลดการเรียกระบบไฟล์
- ใช้ upstream keepalive หากเป็น reverse proxy
- ปิดใช้งาน access logs สำหรับ static files
- ตั้ง expires headers สำหรับ static content
- ใช้ SSL session caching
- Tune kernel parameters ให้เหมาะสม
- ใช้ benchmarking tools เพื่อวัด impact
- Monitor metrics ตลอดเวลา
- Test changes ในสภาพแวดล้อม staging ก่อน production
สรุป
การปรับแต่ง Nginx ให้ได้ประสิทธิภาพสูงสุดนั้นเป็นกระบวนการที่ต้องการความเข้าใจเกี่ยวกับระบบ web infrastructure และการวัดผล ด้วยการตั้งค่า worker processes, keepalive connections, buffer sizes, SSL caching, และ kernel parameters ให้เหมาะสม คุณจะสามารถปรับปรุงประสิทธิภาพของเว็บไซต์ได้อย่างมีนัยสำคัญ
อย่าลืมว่า “premature optimization is the root of all evil” — ควรระบุ bottleneck ที่แท้จริงด้วย monitoring และ profiling tools ก่อนที่จะทำการเปลี่ยนแปลง และควร test ทุกการเปลี่ยนแปลงในสภาพแวดล้อม staging ก่อนที่จะนำไปใช้ในระบบ production
แนะนำบริการ DE Cloud VPS และ Cloud Hosting
หากคุณกำลังมองหา hosting solution ที่เหมาะสำหรับการรัน Nginx ประสิทธิภาพสูง DE Cloud VPS เป็นตัวเลือกที่ดีเยี่ยม ด้วยสัญญาบริหาร 99.9% uptime, full root access, และ resources ที่ประกัน คุณจะสามารถ optimize Nginx configuration ได้อย่างเต็มที่
สำหรับผู้ที่ต้องการ managed hosting solution ที่มีการ pre-optimize Nginx, automatic backups, และ security updates DE Cloud Hosting นำเสนอแพคเกจที่ทำให้คุณสามารถมุ่งเน้นไปที่เนื้อหา business logic แทนที่จะ worry เกี่ยวกับ infrastructure management
ทั้ง Cloud VPS และ Cloud Hosting ของ DE ใช้ SSD storage, advanced networking, และ data center ที่อยู่ในประเทศไทยซึ่งให้ latency ต่ำสำหรับผู้ใช้งานในประเทศไทย เลือกโซลูชันที่เหมาะสมกับความต้องการ business ของคุณและเริ่มต้น optimize ประสิทธิภาพของเว็บไซต์ได้ตั้งแต่วันนี้!

