❶ nginx 緩存配置,對後端java服務有性能提升嗎
這個要看實際情況，涉及緩存命中率，如果後端全部都是動態數據，那麼根本無法緩存，所以沒有任何提升
❷ nginx緩存性能怎麼樣
Nginx緩存對於不少人來說都不是很明朗的一個知識。那麼好我們就借介紹有關優點和缺點的機會把大家帶進Nginx緩存的世界。希望大家在文中能找到自己相關的使用方法。
兩種Nginx緩存都有著基本一樣的優點和缺點：
缺點1：不支持帶參數的動態鏈接，比如read.php?id=1，因為Nginx緩存只保存文件名，所以這個鏈接只在文件系統下保存為read.php，這樣用戶訪問read.php?id=2時會返回不正確的結果。同時不支持http://www.sudone.com/這種形式的首頁和二級目錄http://www.sudone.com/download/，因為Nginx緩存非常老實，會將這樣的請求照鏈接寫入文件系統，而這個鏈接顯然是一個目錄，所以保存失敗。這些情況都需要寫rewrite才能正確保存。
缺點2：Nginx緩存內部沒有緩存過期和清理的任何機制，這些緩存的文件會永久性地保存在機器上，如果要緩存的東西非常多，那就會撐暴整個硬碟空間。為此可以使用一個shell腳本定期清理，同時可以撰寫php等動態程序來做實時更新。
缺點3：只能緩存200狀態碼，因此後端返回301/302/404等狀態碼都不會緩存，假如恰好有一個訪問量很大的偽靜態鏈接被刪除，那就會不停穿透導致後端承載不小壓力。
缺點4：Nginx不會自動選擇內存或硬碟作為存儲介質，一切由配置決定，當然在當前的操作系統里都會有操作系統級的文件緩存機制，所以存在硬碟上也不需要過分擔心大並發讀取造成的io性能問題。
Nginx傳統緩存的缺點也是它和squid等緩存軟體的不同之特色，所以也可看作其優點。在生產應用中它常常用作和squid的搭檔，squid對於帶?的鏈接往往無法阻擋，而Nginx能將其訪問攔住，例如：http://sudone.com/?和http://sudone.com/在squid上會被當做兩個鏈接，所以會造成兩次穿透；而Nginx只會保存一次，無論鏈接變成http://sudone.com/?1還是http://sudone.com/?123，均不能透過Nginx緩存，從而有效地保護了後端主機。
Nginx緩存會非常老實地將鏈接形式保存到文件系統中，這樣對於一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態和內容，也可以很方便地和別的文件管理器如rsync等配合使用，它完完全全就是一個文件系統結構。
這兩種傳統緩存都可以在linux下將文件保存到/dev/shm里，一般我也是這么做的，這樣可以利用系統內存來做緩存，利用內存的話，清理過期內容速度就會快得多。使用/dev/shm/時除了要把tmp目錄也指向到/dev/shm這個分區外，如果有大量小文件和目錄，還要修改一下這個內存分區的inode數量和最大容量：
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
上面的命令在一台有3G內存的機器上使用，因為/dev/shm默認最大內存是系統內存的一半就是1500M，這條命令將其調大成2500M，同時shm系統inode數量默認情況下可能是不夠用的，但有趣的是它可以隨意調節，這里調節為480000保守了點，但也基本夠用了。
❸ magento如何實施正確的緩存策略以達到最佳性能
本篇文章主要介紹一下在maegnto里cache(File System, APC, Memcached, Redis)的使用，及在不同的伺服器環境中改怎麼使用讓其性能達到最佳。
理解magento的Two-Level Caching
magento默認使用zend framework的二層緩存存儲方式。就是說它使用兩層結構對cache進行配合管理，一個快的，但大小有限制的結構是一層比如APC或者Memcached ，一個比較慢的結構作為第二層比如file system.每一種存儲結構各有利弊，要不同情況不同分析使用，APC 和 Memcached 是使用 key/value來存儲cache，他們都不支持tag。File system 和Redis 支持tag.
magento二級緩存結構工作流程圖示 (Thanks to Fabrizio Branca)：
magento自帶的各種後端緩存介紹：
File system (var/cache)
默認情況下，Magento 將它的緩存條目存儲在file系統中，在var/cache/下可查看。這種情況很適合小型的，數據量不大的站點。但是對於大型的站點，隨著瀏覽量的不斷增多，對file的讀寫操作也將越來越多，站點也會越來越慢。magento是由tags來對cache進行組織管理的，這意味著可以對某一個cache組（相同的tag為一個group）進行操作。
優點：這是默認的，不需要裝額外的軟體
缺點：清除cache依賴於tag，通常修改某個proct或處理某個order完之後，對應的前台頁面都需要更新緩存。每次更新緩存時，都需要根據tag進行所有條目即file進行查找，試想如果站點有多於1000個proct，整個cache的大小將會大於50MB，大約有3500個file，你能想像到每次更新cache都要對3500個file進行查找有多慢嗎。
小提示
1：使用 SSD 替代普通硬碟
2：把var/cache接入 tmpfs
----------------------------------------------------------------------------------------------------------------------------------
APC – Alternative PHP Cache (Key/Value)
APC是一個免費，開源且強健的框架用來緩存和優化 PHP 的中間代碼。
優點：相對於file cache system是很快了
缺點:不支持tag，所以依然需要file system作為slow level cache。伺服器需要安裝PHP APC 模塊
小提示：確保有足夠的內存給APC ，可在 php.ini 中修改參數apc.shm_size
Configuration (app/etc/local.xml)
<global>
...
<cache>
<backend>apc</backend>
<prefix>mgt_</prefix>
</cache>
...
</global>
Settings for php.iniapc.enabled = 1
apc.optimization = 0
apc.shm_segments = 1
apc.shm_size = 768M
apc.ttl = 48000
apc.user_ttl = 48000
apc.num_files_hint = 8096
apc.user_entries_hint = 8096
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.enable_cli = 1
apc.cache_by_default = 1
apc.max_file_size = 10M
apc.include_once_override = 0
---------------------------------------------------------------------------------------------------------------------------
Memcached (Key/Value)
Memcache是一個高性能的分布式的內存對象緩存系統，通過在內存里維護一個統一的巨大的hash表，它能夠用來存儲各種格式的數據，包括圖像、視頻、文件以及資料庫檢索的結果等。簡單的說就是將數據調用到內存中，然後從內存中讀取，從而大大提高讀取速度。
優點：更快的存取速度
缺點：不支持tag，所以依然需要file system作為slow level cache
需求：1：Memcached server 2： PHP extension for memcached
Configuration (app/etc/local.xml)<global>
...
<cache>
<backend>memcached</backend><!-- apc / memcached / empty=file -->
<memcached><!-- memcached cache backend related config -->
<servers><!-- any number of server nodes can be included -->
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[1]]></persistent>
</server>
</servers>
<compression><![CDATA[0]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</cache>
...
</global>
---------------------------------------------------------------------------------------------------------------------
Redis – Advanced key-value store with full cache tag support
magento允許我們使用redis server作為中央存儲倉庫，它支持tag的使用，所以不再需要file system作為slow level cache。在多伺服器多站點環境中，強烈推薦使用redis
，用一個中央緩存倉庫，對所有server cache進行管理。
優點：快；支持tag；已在一個日均ip為500000的站點做過測試，性能極好且穩定。
需求：1：伺服器上需要裝Redis 2：PHP 擴展 phpredis 需要安裝 3：Magento擴展「Cm_Cache_Backend_Redis」需要安裝
Installation
1. Install redis (2.4+ required)
2. Install phpredis
3. Install the magento extension 「Cm_Cache_Backend_Redis」
4. Edit your app/etc/local.xml
<global>
...
<cache>
<backend>Cm_Cache_Backend_Redis</backend>
<backend_options>
<server>127.0.0.1</server> <!-- or absolute path to unix socket -->
<port>6379</port>
<persistent></persistent>
<database>0</database>
<password></password>
<force_standalone>0</force_standalone>
<connect_retries>1</connect_retries>
<automatic_cleaning_factor>0</automatic_cleaning_factor>
<compress_data>1</compress_data>
<compress_tags>1</compress_tags>
<compress_threshold>20480</compress_threshold>
<compression_lib>gzip</compression_lib> <!-- Supports gzip, lzf and snappy -->
</backend_options>
</cache>
...
</global>
轉載僅供參考，版權屬於原作者
❹ 三級緩存對性能的影響
CPU三級緩存旨在讀取第二級緩存之後的丟失數據。在具有三級高速緩存的CPU中，僅需要從內存中調用大約5％的數據，這進一步提高了CPU的效率。運作原理是使用更快的存儲設備來保留從慢速存儲設備讀取的數據的副本。當需要從速度較慢的存儲中讀取和寫入數據時，緩存可以進行讀取。寫入操作首先在快速設備上完成，因此系統將更快地響應。
三級緩存對性能的影響
1.縮短延遲：訪問緩存的時間應盡可能縮短。用很多種方法簡短這個時間，例如通過減小緩存的大小或相關性來減少緩存的延遲，以及諸如預測和增加帶寬的方法。
2.提高命中率：所謂的命中率是在高速緩存中找到內存引用的速率。我們希望首先從緩存中獲取信息以獲得速度優勢，因此緩存需要最大限度地實現這一目標。對於單個緩存，大小，關聯性和塊大小確定命中率。
3.降低更低級別內存下的開銷：緩存是內存層次結構的一部分，其性能會影響其他性能。如果花在其他內存處理上的時間越長，那麼系統性能就越低，這意味著處理將盡可能多地在緩存中完成。
❺ cpu二級緩存對其性能的影響有多大呢
分類: 電腦/網路 >> 硬體
問題描述:
是不是越大越好呢
與內存的大小有沒有對應關系
解析:
CPU的二級緩存和內存大小無關.
設置緩存,最主要的目標,就是為了獲得最大的"數據命中率".
CPU處理各方面送過來的信息,其方式有兩種,一個,就是讀取數據.再一個,就是讀取地址.
而為了提高CPU的命中率,所以設置了一級緩存和二級緩存,先將一些信息(數據位/地址位)先存放在緩存中,然後根據一些規則(比如說,先來先得,或是大塊地址先得等)來對這些數據進行取捨以及更新.
緩存太小,預讀的信息命中的機率就小.
緩存太大,更新緩存的時間就越長,相對命中率也就小了.
所以,在緩存大小之間如何取捨,以及一二級緩存的大小如何調配,就成了CPU製造商所要面臨的重大難題.
數據的讀取命中率,也就直接影響了CPU的性能.
❻ CPU緩存對性能的影響有多大比如同一個CPU一個緩存1M另一個2M他們差別大不。CPU為什麼要分
首先，緩存越大越好。
CPU緩存（Cache Memory）是位於CPU與內存之間的臨時存儲器，它的容量比內存小的多但是交換速度卻比內存要快得多。緩存的出現主要是為了解決CPU運算速度與內存讀寫速度不匹配的矛盾，CPU要讀取一個數據時，首先從緩存中查找，如果找到就立即讀取並送給CPU處理；如果沒有找到，就用相對慢的速度從內存中讀取並送給CPU處理
但受技術、製作工藝、成本、體積等影響，不能做的很大，如果緩存太大，讀取速度受影響。
緩存的結構和大小對CPU速度的影響非常大。CPU一個緩存1M另一個2M他們差別還是很大的，價格也差別大。
CPU的緩存三個級別簡單來說區別在於讀取順序。
普通上網和一般的游戲比如DNF和穿越需要多少緩存？這個當然是越大越好，
❼ 如何利用Nginx的緩沖，緩存優化提升性能
反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下，可以很大程度上能通過利用Nginx的緩沖和緩存功能減輕。
當代理到另一台伺服器，兩個不同的連接速度會影響客戶的體驗：
從客戶機到Nginx代理的連接。
從Nginx代理到後端伺服器的連接。
Nginx具有優化這些連接調整其行為的能力。
如果沒有緩沖，數據從代理的伺服器發送並立即開始被發送到客戶。如果假定客戶端很快，緩沖可以關閉而盡快使數據到客戶端，有了緩沖，Nginx 代理將暫時存儲後端的響應，然後按需供給數據給客戶端。如果客戶端是緩慢的，允許Nginx伺服器關閉到後端的連接。然後，它可以處理數據分配到客戶端， 以任何可能的速度。
Nginx默認有緩沖設計，因為客戶端往往有很大的不同的連接速度。我們可以用以下指令調節緩沖行為。可以在HTTP，server或 location位置來設置。重要的是要記住，大小size指令是針對每個請求配置的，所以增加超出你需求會影響你的性能，如果這時有許多客戶端請求：
proxy_buffering：該指令控制緩沖是否啟用。默認情況下，它的值是「on」。
proxy_buffers：該指令控制代理響應緩沖區的數量（第一個參數）和大小（第二個參數）。默認配置是8個緩沖區大小等於一個內存頁（4K或者8K）。增加緩沖區的數目可以讓你緩沖更多信息。
proxy_buffer_size：從後端伺服器的響應頭緩沖區大小，它包含headers，和其他部分響應是分開的。該指令設置響應部分的緩沖區大小。默認情況下，它和proxy_buffers是相同的尺寸，但因為這是用於頭信息，這通常可以設置為一個較低的值。
proxy_busy_buffers_size：此指令設置標注「client-ready」緩沖區的最大尺寸。而客戶端可以一次讀取來自一個緩沖區的數據，緩沖被放置在隊列中，批量發送到客戶端。此指令控制允許是在這種狀態下的緩沖空間的大小。
proxy_max_temp_file_size：這是每個請求能用磁碟上臨時文件最大大小。這些當上游響應太大不能裝配到緩沖區時被創建。
proxy_temp_file_write_size：這是當被代理伺服器的響應過大時Nginx一次性寫入臨時文件的數據量。
proxy_temp_path：當上游伺服器的響應過大不能存儲到配置的緩沖區域時，Nginx存儲臨時文件硬碟路徑。
正如你所看到的，Nginx提供了相當多的不同的指令來調整緩沖行為。大多數時候，你不必擔心太多，但它對於調整一些值可能是有用的。可能最有用的調整是proxy_buffers和proxy_buffer_size指令。
❽ 如何利用Nginx的緩沖，緩存優化提升性能
使用緩沖釋放後端伺服器
反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下，可以很大程度上能通過利用Nginx的緩沖和緩存功能減輕。
當代理到另一台伺服器，兩個不同的連接速度會影響客戶的體驗：
從客戶機到Nginx代理的連接。
從Nginx代理到後端伺服器的連接。
Nginx具有優化這些連接調整其行為的能力。
如果沒有緩沖，數據從代理的伺服器發送並立即開始被發送到客戶。如果假定客戶端很快，緩沖可以關閉而盡快使數據到客戶端，有了緩沖，Nginx 代理將暫時存儲後端的響應，然後按需供給數據給客戶端。如果客戶端是緩慢的，允許Nginx伺服器關閉到後端的連接。然後，它可以處理數據分配到客戶端， 以任何可能的速度。
Nginx默認有緩沖設計，因為客戶端往往有很大的不同的連接速度。我們可以用以下指令調節緩沖行為。可以在HTTP，server或 location位置來設置。重要的是要記住，大小size指令是針對每個請求配置的，所以增加超出你需求會影響你的性能，如果這時有許多客戶端請求：
proxy_buffering：該指令控制緩沖是否啟用。默認情況下，它的值是「on」。
proxy_buffers：該指令控制代理響應緩沖區的數量（第一個參數）和大小（第二個參數）。默認配置是8個緩沖區大小等於一個內存頁（4K或者8K）。增加緩沖區的數目可以讓你緩沖更多信息。
proxy_buffer_size：從後端伺服器的響應頭緩沖區大小，它包含headers，和其他部分響應是分開的。該指令設置響應部分的緩沖區大小。默認情況下，它和proxy_buffers是相同的尺寸，但因為這是用於頭信息，這通常可以設置為一個較低的值。
proxy_busy_buffers_size：此指令設置標注「client-ready」緩沖區的最大尺寸。而客戶端可以一次讀取來自一個緩沖區的數據，緩沖被放置在隊列中，批量發送到客戶端。此指令控制允許是在這種狀態下的緩沖空間的大小。
proxy_max_temp_file_size：這是每個請求能用磁碟上臨時文件最大大小。這些當上游響應太大不能裝配到緩沖區時被創建。
proxy_temp_file_write_size：這是當被代理伺服器的響應過大時Nginx一次性寫入臨時文件的數據量。
proxy_temp_path：當上游伺服器的響應過大不能存儲到配置的緩沖區域時，Nginx存儲臨時文件硬碟路徑。
正如你所看到的，Nginx提供了相當多的不同的指令來調整緩沖行為。大多數時候，你不必擔心太多，但它對於調整一些值可能是有用的。可能最有用的調整是proxy_buffers和proxy_buffer_size指令。
一個例子：、
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_pass http://example.com;
配置代理服務緩存來減少響應時間
盡管緩沖可以幫助釋放後端伺服器以處理更多的請求，Nginx還提供了一種方法來緩存從後端伺服器的內容，對於許多請求無需連接到上游。
配置代理緩存
要設置緩存用於代理內容，我們可以使用proxy_cache_path指令。這將創建區域保存來自被代理伺服器返回的數據。該proxy_cache_path指令必須在HTTP上下文部分進行設置。
在下面的例子中，我們將配置一些相關的指令來建立我們的緩存系統。
# http context
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
用proxy_cache_path指令，我們首先應該已經定義在文件系統中希望存儲緩存的目錄。在這個例子中，我們選擇在/var/lib/nginx/cache目錄。如果該目錄不存在，你可以用正確的許可權和所有權創建它：
sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache
levels=參數指定緩存將如何組織。 Nginx將通過散列鍵（下方配置）的值來創建一個緩存鍵。我們選擇了上述的levels決定了單個字元目錄（這是散列值的最後一個字元）配有兩個字元的 子目錄（下兩個字元取自散列值的末尾）將被創建。你通常不必對這個細節關注，但它可以幫助Nginx快速找到相關的值。
keys_zone=參數定義緩存區域的名字，我們稱之為backcache。這也是我們定義多少元數據存儲的地方。在這個例子里，我們是存儲8 MB的key。對於每兆位元組，Nginx可存儲8000左右的條目。MAX_SIZE參數設置實際緩存數據的最大尺寸。
我們使用上面的另一個指令是proxy_cache_key。這個設置將設置用於存儲緩存值的鍵。此鍵用於檢查是否一個請求可以從高速緩存提供服務。我們將它設置成方案（http或https），HTTP請求方法，以及被請求的主機和URI的組合。
proxy_cache_valid指令可以被指定多次。它依賴於狀態代碼值使我們能夠配置多長時間存儲。在我們的例子中，我們對於後端返回200和302存儲10分鍾，404響應的一分鍾過期。
現在，我們已經配置了緩存區，但我們仍然需要告訴Nginx什麼時候使用緩存。
在我們代理到後端的location位置，我們可以配置使用這個緩存：
# server context
location /proxy-me {
proxy_cache backcache;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_pass http://backend;
}
使用proxy_cache指令，就可以指定該backcache緩存區被用於這個位置。 Nginx會在這里檢查傳遞給後端有效的條目。
上述proxy_cache_bypass指令被設置為$ http_cache_control變數。這將包含一個指示器，用以指示該客戶端是否被明確地請求一個最新的，非緩存版本。設置此指令允許Nginx正確處理這些類型的客戶端請求。無需進行進一步的配置。
我們還增加了被稱為X-Proxy-Cache的額外頭。我們設置這個頭部為$ upstream_cache_status變數的值。這個設置頭，使我們能夠看到，如果請求導致高速緩存命中，高速緩存未命中，或者高速緩存被明確旁 路。這是對於調試特別有價值，也對客戶端是有用的信息。
關於緩存結果的注意事項
高速緩存能夠極大地提高代理伺服器的性能。不過，也需要明確的考慮配置緩存時候，要記住。
首先，任何用戶相關的數據不應被高速緩存。這可能導致一個用戶的數據被呈現給其他用戶。如果你的網站是完全靜態的，這可能不是一個問題。
如果你的網站有一些動態元素，你將不得不考慮到這一點。你如何處理要看是什麼應用程序或伺服器處理的後端處理。對於私人的內容，你應該設置Cache-Control頭為「no-cache」，「no-sotre」，或者「private」依賴於數據的性質：
no-cache：
請求: 告知緩存者，必須原原本本的轉發原始請求,並告知任何緩存者,需要去轉發請求,並驗證緩存(如果有的話).對應名詞:端對端重載.
響應: 允許緩存者緩存副本.那麼其實際價值是,總是強制緩存者,校驗緩存的新鮮度.一旦確認新鮮,則可以使用緩存副本作為響應. no-cache,還可以指定某個包含欄位,比如一個典型應用,no-cache=Set-Cookie. 這樣做的結果,就是告知緩存者,對於Set-Cookie欄位,你不要使用緩存內容.而是使用新滴.其他內容則可以使用緩存
no-store：表示在任何時候收到的數據不被緩存。這對於私人數據是最安全，因為它意味著，該數據必須從伺服器每次進行檢索。
private：這表明共享的緩存空間不能緩存此數據。這可以用於指示用戶的瀏覽器高速緩存數據，但代理伺服器不應當考慮隨後的請求數據有效。
public：這表明該響應是可在連接的任何點被高速緩存的公共數據。
一個相關的可以控制此行為報頭是max-age頭，其指示，任何資源應該緩存的秒數。
根據內容的敏感性，正確設置這些頭，會幫助你利用緩存優勢，同時保持你的私人數據安全，並使您的動態數據最新。
如果你的後端也使用Nginx，你可以設置使用過期指令，設置max-age來實現Cache-Control：
location / {
expires 60m;
}
location /check-me {
expires -1;
}
在上面的例子中，第一個塊允許緩存一個小時的內容。第二塊設置Cache-Control頭為「無緩存」。要設置其他值，可以使用add_header指令，就像這樣：
location /private {
expires -1;
add_header Cache-Control "no-store";
}
❾ 如何提升Web後端性能
1： 優化自己的軟體程序
2：項目分布式部署
3：大量數據可以採用緩存的方式