Nginx在高並發下的性能優化點!有這篇就夠了!

2020-12-16 酷扯兒

本文轉載自【微信公眾號:java進階架構師,ID:java_jiagoushi】經微信公眾號授權轉載,如需轉載與原文作者聯繫

前面幾周,講過Nginx的日誌配置:Nginx | 超詳細!Nginx 日誌配置實踐,然後也講了Nginx的進程模型,底層原理等:Nginx為什麼快到根本停不下來?沒看過的可以先看看(連結點擊可跳轉)。

例如:Nginx 的進程模型

本篇,我們則來講講Nginx的幾種性能優化方式

目錄[-]

1、Nginx運行工作進程數量

Nginx運行工作進程個數一般設置CPU的核心或者核心數x2。如果不了解cpu的核數,可以top命令之後按1看出來,也可以查看/proc/cpuinfo文件 grep ^processor /proc/cpuinfo | wc -l。

[root@lx~]# vi/usr/local/nginx1.10/conf/nginx.confworker_processes 4;[root@lx~]# /usr/local/nginx1.10/sbin/nginx-s reload[root@lx~]# ps -aux | grep nginx |grep -v greproot 9834 0.0 0.0 47556 1948 ? Ss 22:36 0:00 nginx: master processnginxwww 10135 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10136 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10137 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker processwww 10138 0.0 0.0 50088 2004 ? S 22:58 0:00 nginx: worker process

2、Nginx運行CPU親和力

比如4核配置:

worker_processes 4;worker_cpu_affinity 0001 0010 0100 1000

比如8核配置:

worker_processes 8;worker_cpu_affinity 00000001 00000010 00000100 0000100000010000 00100000 01000000 10000000;

worker_processes最多開啟8個,8個以上性能提升不會再提升了,而且穩定性變得更低,所以8個進程夠用了。

3、Nginx最大打開文件數

worker_rlimit_nofile 65535;

這個指令是指當一個nginx進程打開的最多文件描述符數目,理論值應該是最多打開文件數(ulimit -n)與nginx進程數相除,但是nginx分配請求並不是那麼均勻,所以最好與ulimit -n的值保持一致。

註:文件資源限制的配置可以在/etc/security/limits.conf設置,針對root/user等各個用戶或者*代表所有用戶來設置。

* soft nofile 65535* hard nofile 65535

用戶重新登錄生效(ulimit -n)

4、Nginx事件處理模型

events {use epoll; worker_connections 65535; multi_accept on;}

nginx採用epoll事件模型,處理效率高。

work_connections是單個worker進程允許客戶端最大連接數,這個數值一般根據伺服器性能和內存來制定,實際最大值就是worker進程數乘以work_connections。

實際我們填入一個65535,足夠了,這些都算並發值,一個網站的並發達到這麼大的數量,也算一個大站了!

multi_accept 告訴nginx收到一個新連接通知後接受儘可能多的連接,默認是on,設置為on後,多個worker按串行方式來處理連接,也就是一個連接只有一個worker被喚醒,其他的處於休眠狀態,設置為off後,多個worker按並行方式來處理連接,也就是一個連接會喚醒所有的worker,直到連接分配完畢,沒有取得連接的繼續休眠。當你的伺服器連接數不多時,開啟這個參數會讓負載有一定的降低,但是當伺服器的吞吐量很大時,為了效率,可以關閉這個參數。

5、開啟高效傳輸模式

http {include mime.types; default_type application/octet-stream; …… sendfile on; tcp_nopush on; ……}

Include mime.types :媒體類型,include 只是一個在當前文件中包含另一個文件內容的指令。default_type application/octet-stream :默認媒體類型足夠。sendfile on:開啟高效文件傳輸模式,sendfile指令指定nginx是否調用sendfile函數來輸出文件,對於普通應用設為 on,如果用來進行下載等應用磁碟IO重負載應用,可設置為off,以平衡磁碟與網絡I/O處理速度,降低系統的負載。注意:如果圖片顯示不正常把這個改成off。tcp_nopush on:必須在sendfile開啟模式才有效,防止網路阻塞,積極的減少網絡報文段的數量(將響應頭和正文的開始部分一起發送,而不一個接一個的發送。)6、連接超時時間

主要目的是保護伺服器資源,CPU,內存,控制連接數,因為建立連接也是需要消耗資源的。

keepalive_timeout 60;tcp_nodelay on;client_header_buffer_size 4k;open_file_cache max=102400 inactive=20s;open_file_cache_valid 30s;open_file_cache_min_uses 1;client_header_timeout 15;client_body_timeout 15;reset_timedout_connection on;send_timeout 15;server_tokens off;client_max_body_size 10m;

keepalived_timeout :客戶端連接保持會話超時時間,超過這個時間,伺服器斷開這個連結。tcp_nodelay:也是防止網絡阻塞,不過要包涵在keepalived參數才有效。client_header_buffer_size 4k:客戶端請求頭部的緩衝區大小,這個可以根據你的系統分頁大小來設置,一般一個請求頭的大小不會超過 1k,不過由於一般系統分頁都要大於1k,所以這裡設置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得。open_file_cache max=102400 inactive=20s :這個將為打開文件指定緩存,默認是沒有啟用的,max指定緩存數量,建議和打開文件數一致,inactive 是指經過多長時間文件沒被請求後刪除緩存。open_file_cache_valid 30s:這個是指多長時間檢查一次緩存的有效信息。open_file_cache_min_uses 1 :open_file_cache指令中的inactive 參數時間內文件的最少使用次數,如果超過這個數字,文件描述符一直是在緩存中打開的,如上例,如果有一個文件在inactive 時間內一次沒被使用,它將被移除。client_header_timeout :設置請求頭的超時時間。我們也可以把這個設置低些,如果超過這個時間沒有發送任何數據,nginx將返回request time out的錯誤。client_body_timeout設置請求體的超時時間。我們也可以把這個設置低些,超過這個時間沒有發送任何數據,和上面一樣的錯誤提示。reset_timeout_connection :告訴nginx關閉不響應的客戶端連接。這將會釋放那個客戶端所佔有的內存空間。send_timeout :響應客戶端超時時間,這個超時時間僅限於兩個活動之間的時間,如果超過這個時間,客戶端沒有任何活動,nginx關閉連接。server_tokens :並不會讓nginx執行的速度更快,但它可以關閉在錯誤頁面中的nginx版本數字,這樣對於安全性是有好處的。client_max_body_size:上傳文件大小限制。7、fastcgi 調優

fastcgi_connect_timeout 600;fastcgi_send_timeout 600;fastcgi_read_timeout 600;fastcgi_buffer_size 64k;fastcgi_buffers 4 64k;fastcgi_busy_buffers_size 128k;fastcgi_temp_file_write_size 128k;fastcgi_temp_path/usr/local/nginx1.10/nginx_tmp;fastcgi_intercept_errors on;fastcgi_cache_path/usr/local/nginx1.10/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128minactive=1d max_size=10g;

fastcgi_connect_timeout 600 :指定連接到後端FastCGI的超時時間。fastcgi_send_timeout 600 :向FastCGI傳送請求的超時時間。fastcgi_read_timeout 600 :指定接收FastCGI應答的超時時間。fastcgi_buffer_size 64k :指定讀取FastCGI應答第一部分需要用多大的緩衝區,默認的緩衝區大小為。fastcgi_buffers指令中的每塊大小,可以將這個值設置更小。fastcgi_buffers 4 64k :指定本地需要用多少和多大的緩衝區來緩衝FastCGI的應答請求,如果一個php腳本所產生的頁面大小為256KB,那麼會分配4個64KB的緩衝區來緩存,如果頁面大小大於256KB,那麼大於256KB的部分會緩存到fastcgi_temp_path指定的路徑中,但是這並不是好方法,因為內存中的數據處理速度要快於磁碟。一般這個值應該為站點中php腳本所產生的頁面大小的中間值,如果站點大部分腳本所產生的頁面大小為256KB,那麼可以把這個值設置為「8 32K」、「4 64k」等。fastcgi_busy_buffers_size 128k :建議設置為fastcgi_buffers的兩倍,繁忙時候的buffer。fastcgi_temp_file_write_size 128k :在寫入fastcgi_temp_path時將用多大的數據塊,默認值是fastcgi_buffers的兩倍,該數值設置小時若負載上來時可能報502BadGateway。fastcgi_temp_path :緩存臨時目錄。fastcgi_intercept_errors on :這個指令指定是否傳遞4xx和5xx錯誤信息到客戶端,或者允許nginx使用error_page處理錯誤信息。註:靜態文件不存在會返回404頁面,但是php頁面則返回空白頁!fastcgi_cache_path /usr/local/nginx1.10/fastcgi_cachelevels=1:2 keys_zone=cache_fastcgi:128minactive=1d max_size=10g :fastcgi_cache緩存目錄,可以設置目錄層級,比如1:2會生成16*256個子目錄,cache_fastcgi是這個緩存空間的名字,cache是用多少內存(這樣熱門的內容nginx直接放內存,提高訪問速度),inactive表示默認失效時間,如果緩存數據在失效時間內沒有被訪問,將被刪除,max_size表示最多用多少硬碟空間。fastcgi_cache cache_fastcgi :#表示開啟FastCGI緩存並為其指定一個名稱。開啟緩存非常有用,可以有效降低CPU的負載,並且防止502的錯誤放生。cache_fastcgi為proxy_cache_path指令創建的緩存區名稱。fastcgi_cache_valid 200 302 1h :#用來指定應答代碼的緩存時間,實例中的值表示將200和302應答緩存一小時,要和fastcgi_cache配合使用。fastcgi_cache_valid 301 1d :將301應答緩存一天。fastcgi_cache_valid any 1m :將其他應答緩存為1分鐘。fastcgi_cache_min_uses 1 :該指令用於設置經過多少次請求的相同URL將被緩存。fastcgi_cache_key http://$host$request_uri :該指令用來設置web緩存的Key值,nginx根據Key值md5哈希存儲.一般根據$host(域名)、$request_uri(請求的路徑)等變量組合成proxy_cache_key 。fastcgi_pass :指定FastCGI伺服器監聽埠與地址,可以是本機或者其它。總結:

nginx的緩存功能有:proxy_cache / fastcgi_cache

proxy_cache的作用是緩存後端伺服器的內容,可能是任何內容,包括靜態的和動態。fastcgi_cache的作用是緩存fastcgi生成的內容,很多情況是php生成的動態的內容。proxy_cache緩存減少了nginx與後端通信的次數,節省了傳輸時間和後端寬帶。fastcgi_cache緩存減少了nginx與php的通信的次數,更減輕了php和資料庫(mysql)的壓力。8、gzip 調優

使用gzip壓縮功能,可能為我們節約帶寬,加快傳輸速度,有更好的體驗,也為我們節約成本,所以說這是一個重點。

Nginx啟用壓縮功能需要你來ngx_http_gzip_module模塊,apache使用的是mod_deflate。

一般我們需要壓縮的內容有:文本,js,html,css,對於圖片,視頻,flash什麼的不壓縮,同時也要注意,我們使用gzip的功能是需要消耗CPU的!

gzip on;gzip_min_length 2k;gzip_buffers 4 32k;gzip_http_version 1.1;gzip_comp_level 6;gzip_typestext/plain text/css text/javascriptapplication/json application/javascript application/x-javascriptapplication/xml;gzip_vary on;gzip_proxied any;gzip on; #開啟壓縮功能

gzip_min_length 1k :設置允許壓縮的頁面最小字節數,頁面字節數從header頭的Content-Length中獲取,默認值是0,不管頁面多大都進行壓縮,建議設置成大於1K,如果小與1K可能會越壓越大。gzip_buffers 4 32k :壓縮緩衝區大小,表示申請4個單位為32K的內存作為壓縮結果流緩存,默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果。gzip_http_version 1.1 :壓縮版本,用於設置識別HTTP協議版本,默認是1.1,目前大部分瀏覽器已經支持GZIP解壓,使用默認即可。gzip_comp_level 6 :壓縮比例,用來指定GZIP壓縮比,1壓縮比最小,處理速度最快,9壓縮比最大,傳輸速度快,但是處理慢,也比較消耗CPU資源。gzip_types text/css text/xml application/javascript :用來指定壓縮的類型,『text/html』類型總是會被壓縮。默認值: gzip_types text/html (默認不對js/css文件進行壓縮)壓縮類型,匹配MIME型進行壓縮;不能用通配符 text/*;text/html默認已經壓縮 (無論是否指定);設置哪壓縮種文本文件可參考 conf/mime.types。gzip_vary on :varyheader支持,改選項可以讓前端的緩存伺服器緩存經過GZIP壓縮的頁面,例如用Squid緩存經過nginx壓縮的數據。9、expires 緩存調優

緩存,主要針對於圖片,css,js等元素更改機會比較少的情況下使用,特別是圖片,佔用帶寬大,我們完全可以設置圖片在瀏覽器本地緩存365d,css,js,html可以緩存個10來天,這樣用戶第一次打開加載慢一點,第二次,就非常快了!緩存的時候,我們需要將需要緩存的拓展名列出來, Expires緩存配置在server欄位裡面。

location ~* \.(ico|jpe?g|gif|png|bmp|swf|flv)$ {expires 30d;#log_not_found off;access_log off;}location ~* \.(js|css)$ {expires 7d;log_not_found off;access_log off;}

註:log_not_found off;是否在error_log中記錄不存在的錯誤。默認是。

expire功能優點:

expires可以降低網站購買的帶寬,節約成本;同時提升用戶訪問體驗;減輕服務的壓力,節約伺服器成本,是web服務非常重要的功能。expire功能缺點:

被緩存的頁面或數據更新了,用戶看到的可能還是舊的內容,反而影響用戶體驗。解決辦法:第一個縮短緩存時間,例如:1天,但不徹底,除非更新頻率大於1天;第二個對緩存的對象改名。

網站不希望被緩存的內容:

網站流量統計工具;更新頻繁的文件(google的logo)。10、防盜鏈

防止別人直接從你網站引用圖片等連結,消耗了你的資源和網絡流量,那麼我們的解決辦法由幾種:

水印,品牌宣傳,你的帶寬,伺服器足夠;防火牆,直接控制,前提是你知道IP來源;防盜鏈策略下面的方法是直接給予404的錯誤提示。

location ~*^.+\.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {valid_referers noneblocked www.benet.com benet.com;if($invalid_referer) {#return 302 http://www.benet.com/img/nolink.jpg; return 404; break;}access_log off;}

參數可以使如下形式:

none :意思是不存在的Referer頭(表示空的,也就是直接訪問,比如直接在瀏覽器打開一個圖片)。blocked :意為根據防火牆偽裝Referer頭,如:「Referer:XXXXXXX」。server_names :為一個或多個伺服器的列表,0.5.33版本以後可以在名稱中使用「*」通配符。11、內核參數優化

fs.file-max = 999999:這個參數表示進程(比如一個worker進程)可以同時打開的最大句柄數,這個參數直線限制最大並發連接數,需根據實際情況配置。net.ipv4.tcp_max_tw_buckets = 6000 :這個參數表示作業系統允許TIME_WAIT套接字數量的最大值,如果超過這個數字,TIME_WAIT套接字將立刻被清除並列印警告信息。該參數默認為180000,過多的TIME_WAIT套接字會使Web伺服器變慢。註:主動關閉連接的服務端會產生TIME_WAIT狀態的連接net.ipv4.ip_local_port_range = 1024 65000 :允許系統打開的埠範圍。net.ipv4.tcp_tw_recycle = 1 :啟用timewait快速回收。net.ipv4.tcp_tw_reuse = 1 :開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接。這對於伺服器來說很有意義,因為伺服器上總會有大量TIME-WAIT狀態的連接。net.ipv4.tcp_keepalive_time = 30:這個參數表示當keepalive啟用時,TCP發送keepalive消息的頻度。默認是2小時,若將其設置的小一些,可以更快地清理無效的連接。net.ipv4.tcp_syncookies = 1 :開啟SYN Cookies,當出現SYN等待隊列溢出時,啟用cookies來處理。net.core.somaxconn = 40960 :web 應用中 listen 函數的 backlog 默認會給我們內核參數的。net.core.somaxconn :限制到128,而nginx定義的NGX_LISTEN_BACKLOG 默認為511,所以有必要調整這個值。註:對於一個TCP連接,Server與Client需要通過三次握手來建立網絡連接.當三次握手成功後,我們可以看到埠的狀態由LISTEN轉變為ESTABLISHED,接著這條鏈路上就可以開始傳送數據了.每一個處於監聽(Listen)狀態的埠,都有自己的監聽隊列.監聽隊列的長度與如somaxconn參數和使用該埠的程序中listen()函數有關。somaxconn定義了系統中每一個埠最大的監聽隊列的長度,這是個全局的參數,默認值為128,對於一個經常處理新連接的高負載 web服務環境來說,默認的 128 太小了。大多數環境這個值建議增加到 1024 或者更多。大的偵聽隊列對防止拒絕服務 DoS 攻擊也會有所幫助。net.core.netdev_max_backlog = 262144 :每個網絡接口接收數據包的速率比內核處理這些包的速率快時,允許送到隊列的數據包的最大數目。net.ipv4.tcp_max_syn_backlog = 262144 :這個參數標示TCP三次握手建立階段接受SYN請求隊列的最大長度,默認為1024,將其設置得大一些可以使出現Nginx繁忙來不及accept新連接的情況時,Linux不至於丟失客戶端發起的連接請求。net.ipv4.tcp_rmem = 10240 87380 12582912 :這個參數定義了TCP接受緩存(用於TCP接受滑動窗口)的最小值、默認值、最大值。net.ipv4.tcp_wmem = 10240 87380 12582912:這個參數定義了TCP發送緩存(用於TCP發送滑動窗口)的最小值、默認值、最大值。net.core.rmem_default = 6291456:這個參數表示內核套接字接受緩存區默認的大小。net.core.wmem_default = 6291456:這個參數表示內核套接字發送緩存區默認的大小。net.core.rmem_max = 12582912:這個參數表示內核套接字接受緩存區的最大大小。net.core.wmem_max = 12582912:這個參數表示內核套接字發送緩存區的最大大小。net.ipv4.tcp_syncookies = 1:該參數與性能無關,用於解決TCP的SYN攻擊。下面貼一個完整的內核優化設置:

fs.file-max = 999999net.ipv4.ip_forward = 0net.ipv4.conf.default.rp_filter = 1net.ipv4.conf.default.accept_source_route = 0kernel.sysrq = 0kernel.core_uses_pid = 1net.ipv4.tcp_syncookies = 1kernel.msgmnb = 65536kernel.msgmax = 65536kernel.shmmax = 68719476736kernel.shmall = 4294967296net.ipv4.tcp_max_tw_buckets = 6000net.ipv4.tcp_sack = 1net.ipv4.tcp_window_scaling = 1net.ipv4.tcp_rmem = 10240 87380 12582912net.ipv4.tcp_wmem = 10240 87380 12582912net.core.wmem_default = 8388608net.core.rmem_default = 8388608net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.netdev_max_backlog = 262144net.core.somaxconn = 40960net.ipv4.tcp_max_orphans = 3276800net.ipv4.tcp_max_syn_backlog = 262144net.ipv4.tcp_timestamps = 0net.ipv4.tcp_synack_retries = 1net.ipv4.tcp_syn_retries = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_mem = 94500000 915000000 927000000net.ipv4.tcp_fin_timeout = 1net.ipv4.tcp_keepalive_time = 30net.ipv4.ip_local_port_range = 1024 65000

執行sysctl -p使內核修改生效。

12、關於系統連接數的優化

linux 默認值 open files為1024。查看當前系統值:

# ulimit -n1024

說明server只允許同時打開1024個文件。

使用ulimit -a 可以查看當前系統的所有限制值,使用ulimit -n 可以查看當前的最大打開文件數。

新裝的linux 默認只有1024 ,當作負載較大的伺服器時,很容易遇到error: too many open files。因此,需要將其改大,在/etc/security/limits.conf最後增加:

* soft nofile 65535* hard nofile 65535* soft noproc 65535* hard noproc 65535

相關焦點

  • 不知道如何做性能測試,那就從這三方面入手
    通過這兩個案例,我們知道,在一些極限的場景下,軟/件和硬體會造成極大的破壞和損失,因此,我們需要進行性能測試,來驗證軟體在高壓力下,高並發下,高負載下的實際工作情況。2.第三步 —— 了解性能測試需要用到的技術本章節,主要是通過性能測試的原理,了解性能測試需要使用的各方面的知識和技術。性能測試原理介紹:性能測試,本質就是模擬客戶端請求,對伺服器進行高並發,高流量的壓力測試,從而驗證伺服器提供服務的能力,並找出瓶頸點,提出或者進行優化。
  • 支撐百萬高並發內核參數調優
    這些模塊會影響並發性能。在經過這樣的調整之後,除了會進一步提升伺服器的負載能力之外,還能夠防禦小流量程度的DoS、CC和SYN攻擊。此外,如果你的連接數本身就很多,我們可以再優化一下TCP的可使用埠範圍,進一步提升伺服器的並發能力。
  • Java 資料庫設計 性能優化 電商秒殺系統附帶源碼
    課程名稱: JAVA 資料庫設計 性能優化 電商秒殺系統附帶源碼課程簡介: Java 資料庫設計 性能優化 電商秒殺系統附帶源碼----------------------課程目錄----------------------------
  • 「高並發」Redis如何助力高並發秒殺系統,看完這篇我徹底懂了!
    簡單的來說就是一件商品的購買人數遠遠大於這件商品的庫存,而且這件商品在很短的時間內就會被搶購一空。比如每年的618、雙11大促,小米新品促銷等業務場景,就是典型的秒殺業務場景。秒殺業務最大的特點就是瞬時並發流量高,在電商系統中,庫存數量往往會遠遠小於並發流量,比如:天貓的秒殺活動,可能庫存只有幾百、幾千件,而瞬間湧入的搶購併發流量可能會達到幾十到幾百萬。
  • java學習:高並發下的架構解決方案附案列講解
    眾所周知,網際網路分布式系統架構設計必須考慮高並發,高並發也是開發者常常會面臨的一個技術難題。如何控制庫存避免超賣?怎麼實現線程間數據處理的同步?本文將以紅包雨系統業務為例,為大家詳細闡述業務痛點和系統設計的方法,幫助大家梳理解決問題的思路,構建系統思維的能力。
  • 阿里P9耗時28天,總結歷年億級活動高並發系統設計手冊
    :****,好卡啊,對,就是這句好卡了,你不知道在你適應的應用背後,是程式設計師朋友們付出的多少努力無論是618、雙十一以及雙十二都是離不開高並發的。就是在這些不斷地改進過程中,以解決系統中存在的問題為目的和驅動力的系統設計得以進行,而阿里,正是在這方面的最佳實踐者。有人可能會說,他們有伺服器啊(要不把你程序放在他們伺服器上抵抗億級並發的衝擊試試?)阿里作為國內網際網路行業的老大哥,也正是考慮到這一點,不是所有人都能投入那麼多的資金,所以對於系統優化部分,也是不遺餘力。
  • 「技術專刊」WebApi部署多伺服器配置Nginx負載均衡
    Visual Studio2019 --- Vsersion:16.4.4 + NetCore3.1.202PARTNginx快速搭建配置負載均衡Nginx是一款輕量級的Web 伺服器/反向代理伺服器及電子郵件(IMAP/POP3)代理伺服器,在BSD-like 協議下發行
  • 走近伏羲,談5000節點集群調度與性能優化
    5K帶來的挑戰在5K項目攻堅過程中,我們看到大型雲計算平臺從設計到實現每一步都可能存在性能「陷阱」,主要有三方面原因:規模放大效應,當系統擴展到數千節點時,原本非瓶頸與規模成正比的環節,其影響會被放大;木桶效應,很多時候,系統99%的地方都被優化過,完成剩下1%的優化看起來只是「錦上添花」,然而那1%很可能就會成為影響系統性能的致命的瓶頸
  • MySQL count(*),count(1),count(field)區別、性能差異及優化建議
    MySQL count函數是用來獲取表中滿足一定條件的記錄數,常見用法有三種,count(*),count(1),count(field),這三種有什麼區別?在性能上有何差異?本文將通過測試案例詳細介紹和分析。
  • 高並發庫存秒殺場景,阿里巴巴資料庫是這樣應對的
    從上文的架構圖不難看出,所有的商品的庫存信息都存在單一的表和庫裡,當商品種類繁多或者業務並發請求暴漲時,單實例的資料庫顯然會成為容量或者性能瓶頸。該資料庫架構一般只是功能性的實現,主要用於微型庫存系統或者測試使用。
  • 高並發解決方案之秒殺
    一、什麼是高並發高並發(High Concurrency)是網際網路分布式系統架構設計中必須考慮的因素之一,它通常是指,通過設計保證系統能夠同時並行處理很多請求。高並發相關常用的一些指標有響應時間(Response Time),吞吐量(Throughput),每秒查詢率QPS(Query Per Second),並發用戶數等。響應時間:系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms,這個200ms就是系統的響應時間。吞吐量:單位時間內處理的請求數量。
  • 由12306.cn 談談網站性能技術
    這個是需要有一致性的檢查的,也就是在並發時需要對數據加鎖的。B2C的電商基本上都會把這個 事幹成異步的,也就是說,你下的訂單並不是馬上處理的,而是延時處理的,只有成功處理了,系統才會給你一封確認郵件說是訂單成功。我相信有很多朋友都收到 認單不成功的郵件。這就是說,數據一致性在並發下是一個瓶頸。
  • JAVA並發編程:並發問題的根源及主要解決方法
    CPU為了平衡與內存之間的性能差異,引入了CPU緩存,這樣CPU執行指令修改數據的時候就可以批量直接讀寫CPU緩存的內存,一個階段後再將數據寫回到內存。所以高並發場景下,很多時候都會通過鎖實現原子性。而這個問題也是很多並發問題的源頭。編譯器優化帶來的有序性因為現在程式設計師編寫的都是高級語言,編譯器需要將用戶的代碼轉成CPU可以執行的指令。
  • 只知道 Nginx 牛,卻不知道它怎麼支持百萬並發?
    很多高知名度的網站都使用Nginx,比如:Netflix,GitHub,SoundCloud,MaxCDN等。1.4.事件驅動模型基於異步及非阻塞的事件驅動模型,可以說是Nginx得以獲得高並發、高性能的關鍵因素,同時也得益於對Linux、Solaris及類BSD等作業系統內核中事件通知及I/O性能增強功能的採用,如kqueue、epoll及eventports。
  • 高並發與實時處理技術實戰:IT系統架構調優就得這麼玩
    在本次大會上,除了眾星雲集的主論壇環節,12場分論壇更是各具特色,分別聚焦了時下最受關注的容器、AI、區塊鏈、大數據、高並發、物聯網等前沿技術領域。當前,數位化在給企業帶來業務創新,推動企業高速發展的同時,也給企業的IT系統帶來了嚴峻的挑戰。如何利用技術手段使得系統可以並行處理更多的請求,降低延遲和響應時間,提高性能,提升用戶體驗,成為各大企業必須解決的難題。
  • 淺談Nginx負載均衡與F5的區別
    其實Nginx和F5這兩者均可用作網站負載均衡,那二者有什麼區別呢?筆者在此淺談下Nginx與F5的一些區別。目前很多網站或應用在設計之初都會為高並發的數據請求做負載均衡,不差錢的土豪用戶一般會直接買F5硬體設備作為其負載均衡器,原因不用多說,其功能強大,不僅包含負載均衡還包括應用交換、會話交換、狀態監控、智能網絡地址轉換、通用持續性、響應錯誤處理、IPv6網關、高級路由、智能埠鏡像、SSL加速、智能HTTP壓縮、TCP優化、第7層速率整形、內容緩衝、內容轉換、連接加速、高速緩存、Cookie
  • 高並發的中斷下半部tasklet實例解析
    探針點在__elv_add_request內核函數的開頭處打點(trace_block_rq_insert處),如下代碼所示。的並發處理能力。四、高並發的下半部tasklet明確了導致問題的原因,下面還要找到解決問題的方法。
  • Intel自家Linux發行版神優化:AMD Zen3性能高出15%
    對Linux用戶來說,AMD的Zen3處理器現在是最好的CPU,而最佳系統則是Intel的Clear Linux,性能要比其他平臺高出15%。大家都知道Linux有太多發行版了,選擇合適的Linux系統很傷腦筋。
  • SequoiaDB 巨杉資料庫 v3.4 版本正式發布 分布式交易場景性能...
    查詢性能對比示意更新性能對比示意針對分布式交易場景,新版本的技術點主要有以下幾個: Improved 2PC Algorithm分布式事務智能仲裁算法。資料庫集群池化內存資源,內存池多級管理,會話訪問實現 99.99% 內存訪問命中率,實現高並發 OLTP 場景下內存的無鎖訪問,系統CPU的使用率提升 10%;SequoiaDB v3.4同時提供在線內存監控和離線內存分析能力,自動化生成內存分析報告。 Improved Raft Algorithm突破Raft 算法極限,實現全並發同步。
  • 7600字帶你學會 Redis 性能優化點,建議收藏!
    那麼,針對 Redis 服務,我們能做哪些性能優化呢?或者說,應該避免哪些性能浪費呢?Redis 性能的基本面在討論優化之前,我們需要知道,Redis 服務本身就有一些特性,比如單線程運行。除非修改 Redis 的原始碼,不然這些特性,就是我們思考性能優化的基本面。