您好,登錄后才能下訂單哦!
一、遇到的一些問題
記得 2008 年做性能測試的時候,新進7臺 lenovo 4核4G 服務器用于性能測試。
當時資源緊張,這7臺服務器都裝了雙系統(Win2003/CentOS5)空閑時用于做測試機(壓測的Agent)。
當時給Nginx做了一系列測試,印象很深的是:在這批機器上,Nginx狀態頁面的壓測。
短連接的話最佳QPS約4萬,長連接的話最高QPS約13萬。
大概3年后,那批 lenovo 服務器已經沒人瞧得上了,只能做肉雞。
然而,一次不經意的測試,發現再牛的服務器,短連接最佳QPS也高不了多少。而且,測試機的資源沒用完,被測試服務器的資源也用不完,網絡也沒瓶頸。
服務器資源使用率很低,然而響應就是不夠快。
最后,我們發現了瓶頸在監聽的入口!是否可以提高監聽入口的性能?是否可以端口復用?最后我們找到了SO_REUSEPORT。
SO_REUSEPORT支持多個進程或者線程綁定到同一端口,提高服務器程序的性能。
二、解決方案
測試環境
Dell PowerEdge M620 Intel(R)Xeon(R)CPU E5–2620v2@2.10GHz
Linux3.16.0–4–amd64#1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux
Ethernet controller:Broadcom Corporation NetXtreme II BCM5781010Gigabit Ethernet(rev10)
查看編譯參數
Nginx 配置如下:
注意有一個reuse_port參數
user www–data; worker_processes auto; pid/run/nginx.pid; events{ useepoll; multi_accept on; reuse_port on; worker_connections 1048576; } dso{# 動態加載功能模塊 /usr/share/nginx/modules load ngx_http_memcached_module.so; load ngx_http_limit_conn_module.so; load ngx_http_empty_gif_module.so; load ngx_http_scgi_module.so; load ngx_http_upstream_session_sticky_module.so; load ngx_http_user_agent_module.so; load ngx_http_referer_module.so; load ngx_http_upstream_least_conn_module.so; load ngx_http_uwsgi_module.so; load ngx_http_reqstat_module.so; load ngx_http_browser_module.so; load ngx_http_limit_req_module.so; load ngx_http_split_clients_module.so; load ngx_http_upstream_ip_hash_module.so; } http{ include /etc/nginx/mime.types; default_type text/plain; access_log off; sendfile on; tcp_nopush on; tcp_nodelay on; server_tokens off; keepalive_timeout 120; server_names_hash_bucket_size512; server_name_in_redirect off; fastcgi_connect_timeout3s; fastcgi_send_timeout3s; fastcgi_read_timeout3s; fastcgi_buffer_size128k; fastcgi_buffers8128k; fastcgi_busy_buffers_size256k; fastcgi_temp_file_write_size256k; variables_hash_max_size 1024; set_real_ip_from10.0.0.0/8; set_real_ip_from172.28.0.0/16; set_real_ip_from192.168.0.0/16; real_ip_headerX–Forwarded–For; gzip off; gzip_disable“msie6”; gzip_min_length2k; gzip_buffers1664k; gzip_http_version1.1; gzip_comp_level6; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; gzip_vary on; ssl_protocols TLSv1 TLSv1.1TLSv1.2;# Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; access_log/var/log/nginx/access.log; error_log/var/log/nginx/error.log; server{ listen 80backlog=65535; charset utf–8; location/{# 打印Tengine狀態頁 stub_status on;# 開啟狀態頁,依賴 http_stub_status_module 模塊 access_log off;#訪問過程不記日志 } location~^(.*)\/\.(svn|git|hg|bzr|cvs)\/{# 屏蔽這些目錄 deny all; access_log off; log_not_found off; } location~/\.{# 屏蔽.開頭的目錄或文件,比如 .htaccess .bash_history deny all; access_log off; log_not_found off; } location/do_not_delete.html{ access_log off; empty_gif; } } }
壓測 reuse_port
Tengine 早已支持 reuse_port 。開啟 reuse_port 后,你會發現有很多進程同時監聽80端口:
加壓后你會發現,服務器性能可被你榨干:
對比一下測試 reuse_port 的效果,小伙伴們驚呆了(短連接QPS過了24萬)!
真相大白后,你還等什么?
探個究竟
測試過程中由于壓大 TCP: Possible SYN flooding on port 80. ,出大量錯誤 。
于是將并發量降到了6萬 net.core.somaxconn = 65535 。
再關閉 reuse_port 后,我們看下 perf top的情況:
然后再打開 reuse_port ,對比 perf top 的情況:
此時再放大 Nginx 監聽的 back_log ,看下資源使用情況:
我們來看看些時的隊列情況(有入隊過萬了):
然后我們再來挑戰30萬并發(MTT是平均響應時間(ms)):
經過一系列調優,相同環境相同并發量,沒有再出現 TCP: Possible SYN flooding on port 80.。但出現了少量連接超時的情況:
至此測試完畢,開啟reuse_port確實可以讓性能提升3倍,何不試試。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持億速云。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。