Total transferred: 7499000 bytes
HTML transferred: 7227000 bytes
Requests per second: 352.94 [#/sec] (mean)
Time per request: 14.167 [ms] (mean)
Time per request: 2.833 [ms] (mean, across all concurrent requests)
Transfer rate: 2584.61 [Kbytes/sec] received
 

Total transferred: 7454000 bytes
HTML transferred: 7227000 bytes
Requests per second: 2679.47 [#/sec] (mean)
Time per request: 1.866 [ms] (mean)
Time per request: 0.373 [ms] (mean, across all concurrent requests)
Transfer rate: 19503.87 [Kbytes/sec] received 

/ab -n 1000 -c 20 -t 10 http://localhost/index.html

# free -m
total used free shared buffers cached
Mem: 497 346 151 0 11 126
-/+ buffers/cache: 208 289
Swap: 1027 9 1017 

top - 17:16:48 up 7 days, 2:56, 3 users, load average: 4.12, 1.24, 0.44
Tasks: 107 total, 23 running, 75 sleeping, 8 stopped, 1 zombie
Cpu(s): 89.5%us, 4.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 2.5%hi, 3.5%si, 0.0%st
Mem: 509792k total, 299092k used, 210700k free, 12056k buffers
Swap: 1052248k total, 10232k used, 1042016k free, 102124k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11823 nginx 16 0 124m 23m 15m R 63.8 4.7 0:02.69 php-fpm
11810 nginx 16 0 124m 23m 15m R 31.9 4.6 0:02.31 php-fpm
11805 nginx 16 0 124m 23m 15m R 25.9 4.6 0:03.59 php-fpm
11824 nginx 16 0 125m 23m 15m R 21.9 4.8 0:01.19 php-fpm
11806 nginx 16 0 124m 23m 15m R 19.9 4.6 0:03.96 php-fpm
11807 nginx 16 0 125m 23m 15m R 15.0 4.8 0:02.25 php-fpm
11825 nginx 16 0 125m 23m 15m R 15.0 4.8 0:01.55 php-fpm
10715 nginx 15 0 21728 2180 756 S 5.0 0.4 0:01.02 nginx
11123 mysql 15 0 452m 50m 5684 S 1.0 10.1 0:01.65 mysqld 

# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 10144 73552 54424 147776 0 0 1 3 2 16 0 0 99 0 0
31 0 10144 59592 54424 147776 0 0 0 0 2099 858 57 10 33 0 0
31 0 10144 60948 54424 147792 0 0 0 0 1744 762 94 6 0 0 0
31 0 10144 58468 54424 147868 0 0 0 4 1897 681 94 6 0 0 0
31 0 10144 59212 54424 147876 0 0 0 0 1904 842 94 6 0 0 0
34 0 10144 59708 54428 147948 0 0 0 460 1777 828 94 6 0 0 0
32 0 10144 59832 54428 147944 0 0 0 0 1785 835 94 6 0 0 0
32 0 10144 59212 54428 148020 0 0 0 0 1971 763 93 7 0 0 0
31 0 10144 59832 54428 148024 0 0 0 0 1891 896 94 6 0 0 0
31 0 10144 59708 54428 148100 0 0 0 0 2010 769 94 6 0 0 0
32 0 10144 59832 54436 148080 0 0 0 480 1943 855 93 7 0 0 0
34 0 10144 70760 54436 148232 0 0 0 0 2099 1320 92 9 0 0 0
35 0 10144 69560 54436 148444 0 0 0 0 1020 1727 95 5 0 0 0 

cat /etc/security/limits.conf
nginx soft nofile 10240
nginx hard nofile 10240 

2011/08/18 11:36:33 [error] 2723#0: *4 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.3, server: test1, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9000/", host: "192.168.1.35" 

192.168.1.3 - - [18/Aug/2011:11:30:43 +0900] "GET / HTTP/1.1" 502 575 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1" "-"
192.168.1.3 - - [18/Aug/2011:11:30:43 +0900] "GET /favicon.ico HTTP/1.1" 404 201 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1" "-" 

#! /bin/sh
#
# Created by configure

'./configure' \
'--program-prefix=' \
'--prefix=/usr' \
'--exec-prefix=/usr' \
'--disable-debug' \
'--with-pic' \
'--disable-rpath' \
'--with-pear' \
'--with-bz2' \
'--with-exec-dir=/usr/bin' \
'--with-freetype-dir=/usr' \
'--with-png-dir=/usr' \
'--with-xpm-dir=/usr' \
'--enable-gd-native-ttf' \
'--without-gdbm' \
'--with-gettext' \
'--with-gmp' \
'--with-iconv' \
'--with-jpeg-dir=/usr' \
'--with-openssl' \
'--with-pcre-regex=/usr' \
'--with-zlib' \
'--with-layout=GNU' \
'--enable-exif' \
'--enable-ftp' \
'--enable-magic-quotes' \
'--enable-sockets' \
'--enable-fpm' \
'--with-kerberos' \
'--enable-ucd-snmp-hack' \
'--enable-shmop' \
'--enable-calendar' \
'--without-sqlite' \
'--with-libxml-dir=/usr' \
'--enable-xml' \
'--with-libdir=lib64' \
'--with-mysql' \
'--with-gd' \
'--enable-dom' \
'--enable-dba' \
'--without-unixODBC' \
'--enable-pdo' \
'--disable-xmlreader' \
'--disable-xmlwriter' \
'--with-sqlite3' \
'--disable-phar' \
'--disable-fileinfo' \
'--without-pspell' \
'--disable-wddx' \
'--with-curl' \
'--enable-mbstring' \
"$@" 

[global]
pid = /var/run/php-fpm.pid
error_log = /var/log/php-fpm.log
log_level = notice
emergency_restart_threshold = 0
emergency_restart_interval = 0
process_control_timeout = 0
daemonize = yes

[www]
listen = 127.0.0.1:9000
listen.backlog = -1
listen.allowed_clients = 127.0.0.1

listen.owner = nginx
listen.group = nginx
listen.mode = 0666

user = nginx
group = nginx

pm = dynamic
# Mấy cái này phải dựa vào kết quả của benchmark trên của ab, nên mình đưa tạm các tham số này, chạy cũng ổn.
pm.max_children = 30
pm.start_servers = 11
pm.min_spare_servers = 10
pm.max_spare_servers = 25
pm.max_requests = 500
pm.status_path = /status

request_slowlog_timeout = 2
# Cái thằng này quan trọng cực, khi default nó được set là 5? hay sao đó, nhưng chạy dịch vụ gì cũng bị timeout hay bất ổn định, nên phải set thành 10. Bà con nào chạy dịch vụ nào cùng với SQL thì để ý.
request_terminate_timeout= 10
slowlog = /var/log/$pool.log.slow

# do phpinfo() cảnh báo nên phải set cho nó, không có gì đâu.
php_admin_value[date.timezone]=Asia/Tokyo
 

#
user nginx;
worker_processes 2;
# Log file of nginx
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

#----------------------------------------------------------------------
# HTTP Core Module
#
# http://wiki.nginx.org/NginxHttpCoreModule
#
#----------------------------------------------------------------------

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
keepalive_timeout 0;

#Gzip
gzip on;
gzip_http_version 1.0;
gzip_disable "MSIE [1-6]\.";
gzip_disable "Mozilla/4";
gzip_comp_level 2;
gzip_vary on;
gzip_proxied any;
gzip_buffers 4 8k;
server_names_hash_bucket_size 128; # 32/64/128

# Proxy cache (FastCGI)
proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 100 8k;
proxy_cache_path /var/cache/nginx/nginx_cache levels=1:2 keys_zone=czone:4m max_size=50m inactive=120m;
proxy_temp_path /var/cache/nginx/nginx_tmp;
proxy_connect_timeout 60;
proxy_read_timeout 90;
proxy_send_timeout 60;
proxy_cache_valid 200 2h;
proxy_cache_valid 302 2h;
proxy_cache_valid 301 4h;
proxy_cache_valid any 1m;

#
# set header
#
proxy_set_header Host $http_host;
proxy_set_header X-Remote-Addr $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#
# backend
#
upstream backend {
ip_hash;
server 127.0.0.1:9000;
# server 192.168.1.36:9000;
}

#
# The default server
#
server {
listen 80;
server_name test1;

root /opt/public_html;
index index.php;

# Support Clean (aka Search Engine Friendly) URLs
location / {
# try_files $uri $uri/ /index.php?q=$request_uri;

# LoadBlance to backend
proxy_pass http://backend;
#proxy_cache_key $scheme://$backend$request_uri$is_args$args;

}

index index.php index.html index.htm;

# deny running scripts inside writable directories
location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ {
return 403;
error_page 403 /403_error.html;
}

# The parameter fastcgi_pass is set to 127.0.0.1:9000, corresponding to the port that fpm is configured to listen to.
location ~ .*.php$ {
include /etc/nginx/fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

# caching of files
location ~* \.(ico|pdf|flv)$ {
expires 30d;
}

location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
expires 7d;
}

}

# Load config files from the /etc/nginx/conf.d directory
include /etc/nginx/conf.d/*.conf;
} 

Em thử bỏ listen.allowed_clients = 127.0.0.1 ra khỏi www pool coi thử?

Nên tận dụng UNIX domain socket vì nó efficient hơn TCP socket.

Thử đổi trong php-fpm config
listen = 127.0.0.1:9000

thành:
listen = /path/to/a.sock


rồi trỏ nó trong nginx.conf từ:
fastcgi_pass 127.0.0.1:9000;

thành:
fastcgi_pass unix:/path/to/a.sock;
 

location ~ .*.php$ {
include /etc/nginx/fastcgi.conf;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/tmp/fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
 

[www]
listen = /tmp/fpm.sock
listen.backlog = -1
 

fpm.sock mapping-root scim-bridge-0.3.0.socket-0@localhost:0.0 virtual-root.1rn7IL
 

Em dùng proxy_pass http://backend; nhưng em declare "backend" ở đâu? 

#
# backend
#
upstream backend {
ip_hash;
server 127.0.0.1:9000;
#server 192.168.1.36:9000;
} 

[root@localhost ~]# tail -f /var/log/nginx/access.log
192.168.1.3 - - [18/Aug/2011:15:12:55 +0900] "GET / HTTP/1.1" 502 575 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1" "-"

[root@localhost ~]# tail -f /var/log/nginx/error.log
2011/08/18 15:12:55 [error] 3445#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.3, server: test1, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9000/", host: "192.168.1.35"
 

Có hai chuyện:

1. Nếu em đã sử dụng UNIX domain socket trong php-fpm rồi thì không thể dùng server 127.0.0.1:9000 cho "upstream backend" được vì TCP socket cho port 9000 hoàn toàn không hiện diện. Em chỉ có thể chọn UNIX domain socket hoặc TCP socket chớ không thể chọn cả hai.
 

2. Hình như anh hiểu lầm ý em. Cấu hình ở đây em chỉ muốn chạy web service trên nginx chớ không phải dùng nginx làm proxy phải không? Nếu nginx làm web thì nó là web service chớ không phải là proxy service. Em không thể proxy vô backend vì chẳng có backend nào hết. Trong trường hợp của em, "backend" chính là php-fpm chớ không có gì khác.

Nếu em có 2 con apache bên trong thì mới sử dụng nginx làm proxy. Nếu không, không thể chính nginx làm proxy web service của nó được. 

upstream backend {
ip_hash;
server 192.168.1.35:9000;
server 192.168.1.36:9000;
}  

# LoadBlance to backend
proxy_pass http://backend; 

location ~ .*.php$ {
include /etc/nginx/fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
 

to anh Minh: theo em hiểu thì anh đang muốn loadbalance 2 thằng php-fpm,nếu như vậy có lẽ anh nên bỏ proxy_pass trong location / đi,và loadbalance trên fastcgi_pass:

location ~ .*.php$ {
include /etc/nginx/fastcgi.conf;
fastcgi_pass backend;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
} 

Dpm trả lời hoàn toàn chính xác.

Em có thể delare backend bao nhiêu php-fpm instances cũng được và trong location ~ .*.php$ {} thì em chỉ cần pass backend là xong. Cái em bị kẹt là syntax chớ không phải là mô hình. Anh cũng coi lướt nên không nhận ra cái mớ http em nhét vô .

Với câu hỏi của em, em có thể configure nhiều backend nhưng quan trọng là những backend này ở đâu và cần làm những gì? Nếu những backend này chỉ có một mớ php đơn giản để thao tác thì nhiều backend không khác gì mấy bởi vì chính nginx có nhiều workers và php-fpm cũng có nhiều workers. Cả hai có thể handle concurrent và async requests. Cái chính là bottleneck trong việc truy vấn tới CSDL. Em có thể thiết kế để tạo ra hai backends (php-fpm engines) và mỗi backend connect đến 1 CSDL riêng biệt (nằm ở server khác) thì có thể improve rõ. Nếu csdl chạy trên cùng một server thì nên configure db connections để sử dụng luôn UNIX domain socket vì nó nhanh gọn hơn rất nhiều (cái này anh đã test nhiều lần). 

conmale wrote:

Dpm trả lời hoàn toàn chính xác.

Em có thể delare backend bao nhiêu php-fpm instances cũng được và trong location ~ .*.php$ {} thì em chỉ cần pass backend là xong. Cái em bị kẹt là syntax chớ không phải là mô hình. Anh cũng coi lướt nên không nhận ra cái mớ http em nhét vô .

Với câu hỏi của em, em có thể configure nhiều backend nhưng quan trọng là những backend này ở đâu và cần làm những gì? Nếu những backend này chỉ có một mớ php đơn giản để thao tác thì nhiều backend không khác gì mấy bởi vì chính nginx có nhiều workers và php-fpm cũng có nhiều workers. Cả hai có thể handle concurrent và async requests. Cái chính là bottleneck trong việc truy vấn tới CSDL. Em có thể thiết kế để tạo ra hai backends (php-fpm engines) và mỗi backend connect đến 1 CSDL riêng biệt (nằm ở server khác) thì có thể improve rõ. Nếu csdl chạy trên cùng một server thì nên configure db connections để sử dụng luôn UNIX domain socket vì nó nhanh gọn hơn rất nhiều (cái này anh đã test nhiều lần). 

Chu choa, then chốt của vấn đề là đây, em cũng đã đang định làm thữ mà anh trả lời luôn rồi. Em cũng nghi là sẽ bị bottleneck, mà không làm thì lại chả biết làm cách nào khác, nên định nhắm mắt làm đại.

Vậy bây giờ muốn làm 2 webserver, 1DB server thì chắc tiêu bởi bottleneck rồi.

anh nói "Nếu csdl chạy trên cùng một server thì nên configure db connections để sử dụng luôn UNIX domain " socket" thì tất là chỉ chạy 1 con server, không load blance mà cũng không HA được. Cách này có thể tốt, nhưng lỡ con server này teo thi tính sao anh.

 

Có hai dạng nhu cầu và hai giải pháp khác nhau.
1. Nếu dịch vụ web chỉ có nhiều người dùng chớ không phải bị DDoS.
Cái này cần backend mạnh.
2. Nếu dịch vụ web không có nhiều người dùng nhưng có thể bị DDoS.
Cái này cần frontend mạnh.
 

Về khoảng LB và failover thì tất cả phải là x2 theo nguyên tắc. Đối với frontends, LB và failover thì dễ nhưng backend thì hơi căng và phải áp dụng chặt chẽ biện pháp đồng bộ hoá CSDL không thì kẹt. Trong trường hợp tách rời CSDL ra thì không thể dùng UNIX domain socket (ngoại trừ dùng NFS để mount FS). 

1. Pound + Keepalived+ SQL Cluster để LB + failover. Có điều thằng này em chỉ đọc qua chứ chưa chạy thữ, nên cũng nghi ngờ khả năng xử lý của nó thua xa nginx.  

2. Dùng Nginx+fpm rồi chạy SQL Cluster (mysql cluster chẳng hạn). Thêm vào DNS Round robin, cùng lắm là kết hợp monit và giảm TTL khoản 60giây chắc cũng được.  

5. Dùng dịch vụ heartbeat tạo ra mô hình Cold standby em thấy cũng hay, có điều, chạy cái này có vẻ hơi uổng resource, lỡ có bị DDOS, thằng slave đợi thằng master toi mới ngốc đầu dậy được, rồi sau đó đi đời theo thằng master luôn.
 

Đọc một loạt từ trên xuống dưới, thấy tranvanminh thiết kế hệ thống kiểu chịu được request đập vào DB càng nhiều càng tốt thì phải.
 

Nginx chỉ là Web Server có thêm chúc năng Load Balancer và reverse proxy, sao lại đi so sánh với cả cụm thế được. 

Nginx tốt hơn apache ở chỗ nó tạo ra một pool (hàng đợi) và từ từ forward request vào bên trong thay vì đẩy vào một lượt. Nhưng với một hình Web server + phpfpm -- DB thì cũng chừng đó request đập vào DB, cái pool có xây dựng tốt chừng nào đi nữa thì vấn đề chỉ là chết nhanh chậm một tí. Mình không nghĩ Monit là giải pháp cho bài toán HA.
 

Muốn đảm bảo High availability thì đành phải vậy rồi.
Mình suggest bạn dùng:
1. LVS + caching (nginx) + apache + DB thay cho mô hình số một. Muốn đảm bảo LVS ko chết có thể áp dụng thêm BSD UCARP hoặc Wakeamole + OpenAMQ.
2. Tách nginx và php-cgi ở mô hình thứ 2, thay nginx bằng apache và dns round robin đến 2 box nginx. 

Dùng SQL Clusting để giải đáp vấn đề anh conmale nói: "Cái chính là bottleneck trong việc truy vấn tới CSDL." có bạn nào có cao kiến gì không ạ ?  

tranvanminh wrote:

Dùng SQL Clusting để giải đáp vấn đề anh conmale nói: "Cái chính là bottleneck trong việc truy vấn tới CSDL." có bạn nào có cao kiến gì không ạ ?  

Anh đọc câu hỏi của em từ sáng nhưng hôm nay bận quá nên để đó chưa trả lời liền .

Theo kinh nghiêm của anh, giải quyết bottleneck của bất cứ CSDL nào cũng có 2 phần quan trọng:

1. Infrastructure.
2. Code.

Đối với infrastructure, dựa trên nhu cầu cụ thể và kinh phí cụ thể mà hình thành. Tất nhiên kinh phí ít thì chất lượng thấp. Dù có cố gắng tối đa thì cũng bị hạn chế. Chuyện này chắc em biết. Với nhu cầu của em, em cần performance lẫn failover cho nên làm gì thì làm vẫn cần x2 chớ không thể là x1 CSDL được.

Đối với code, cho dù infrastructure có mạnh, có tốt tới đâu mà code "crap" thì vẫn không thể bảo đảm performance được. Bởi vậy, bottleneck vẫn tồn tại. Điều em cần làm là phân tích xem nhu cầu "đọc" nhiều hơn hay "viết" nhiều hơn? Nếu "đọc" nhiều hơn thì lại dễ hơn "viết" nhiều hơn bởi vì em không cần real time replication hoặc synchronisation. Ngược lại, cần "viết" nhiều hơn thì cần chú trọng đến việc caching, relaying những thứ cần "viết" càng nhiều càng tốt. Đây là khía cạnh engineering code làm sao để bảo đảm performance.

Anh giả sử em cần tạo một website mà chủ yếu là độc giả cần lấy thông tin (thư viện online chẳng hạn) thì chắc chắn việc query (đọc) CSDL sẽ nhiều và việc commit (viết) vào CSDL sẽ ít. Bởi vậy, em có thể thiết kể 2 CSDL tách rời và chỉ cần synchronise chúng theo định kỳ. Những ai quản lý thông tin trên CSDL có thể "viết" lên cả 2 CSDL cùng lúc (cái này tuỳ thuộc vào cách thiết kế software quản lý) hoặc em có thể thiết kế để chúng synchronise theo định kỳ thế nào đó cho hợp lý.

Nói chung, khó có thể hình thành giải pháp nếu như chưa rõ requirements của em là gì. 

Em thik mô hình nginx làm reverse proxy nhất,kết hợp với cache_purge module,ddos thoải mái  

location ~ /purge(/.*) {
allow 127.0.0.1;
allow 192.168.1.35;
deny all;
proxy_cache_purge cache_test1 "$scheme://$host$1";
}
} 

Theo em slowris là một phần,như cái đám botnet của stl kia cơ,a thử cái roboo module xem,viết thêm một script chuyển nhưng IP mà không đc log vào verified cho iptables xử lý. 

Dpm wrote:

Theo em slowris là một phần,như cái đám botnet của stl kia cơ,a thử cái roboo module xem,viết thêm một script chuyển nhưng IP mà không đc log vào verified cho iptables xử lý. 

Không biết dạng ddos của stl biến thái thế nào, nhưng mà thường cho web app xử lý trước iptables thì hơi tốn resource đó, nếu ip hoặc payload match với dạng con_limit hay mstring hay gì gì đó của iptables thì mình nghĩ cho iptables hoặc IDS lọc luôn từ trước chứ không đưa qua nginx. Cách này mình thấy anh conmale áp dụng trong các bài ký sự ddos hồi trước rất hiệu quả.
 

Với nginx proxy thì có thể sử dụng limit_conn và limit_zone để giới hạn số connections mà bots (hoặc browsers) tạo. Đây là cách theo anh thấy không uyển chuyển và chính xác bằng việc sử dụng "state" như mod_security làm bởi vì nginx chỉ đơn thuần dựa vào IP để xét đến limit_conn (đặc biệt trong trường hợp nhiều người cùng dùng một foward proxy hoặc cùng share 1 public IP thì sẽ bị khổ sở với cái limit_conn và limit_zone này).  

conmale wrote:

Với nginx proxy thì có thể sử dụng limit_conn và limit_zone để giới hạn số connections mà bots (hoặc browsers) tạo. Đây là cách theo anh thấy không uyển chuyển và chính xác bằng việc sử dụng "state" như mod_security làm bởi vì nginx chỉ đơn thuần dựa vào IP để xét đến limit_conn (đặc biệt trong trường hợp nhiều người cùng dùng một foward proxy hoặc cùng share 1 public IP thì sẽ bị khổ sở với cái limit_conn và limit_zone này).  

Có thể đây là điểm yếu của nginx bởi vì nó chỉ có tính năng ngang hàng với mod_limitipconn của apache mà không có mod_security.

Em vừa đọc lại Doc của mod_security thì thấy có 2 phần giống "state" mà anh nói tại 6.35 SecReadStateLimit, 6.36 SecWriteStateLimit, chắc anh dùng cái này rồi.