網站先快後慢的緩存清除

[tavenger5]

我已經通過並實施了所有可能的優化技巧，我可以找到。這包括nginx的作為代理到Apache，vbOptimize與 memcached的，和所有的常規百度推廣優化程序。

我的工作有兩個雙四核處理器的服務器具有12和***的RAM，和15K SAS驅動器RAID。所以，換句話說，服務器有足夠的力量來處理一切。

主站點開始緩慢右後 vBET緩存被清除每隔15天。 （數據庫獲取到剛剛超過 ***後這 15天的期限）> 50萬頁，每天正在被搜索引擎抓取。

有什麼我可以做調整 Apache來處理這些請求的更好嗎？這些都是我目前的Apache設置：
從 httpd的- mpm.conf
＃prefork的MPM

StartServers的20
MinSpareServers 20
MaxSpareServers 25
MaxClients的180
MaxRequestsPerChild 1000

從 httpd的- default.conf：

逾150
保持活動在
MaxKeepAliveRequests 80
KeepAliveTimeout的3
UseCanonicalName關閉

[vBET]

讓我猜猜 - 你在主頁面上有 vBSEO 和很多連結 - 我是對的？

訣竅是 - 如果你真的沒有來，然後不要使用最後結算的策略。我知道有 若 - 你檢查其他結算策略？其他不會清除整個緩存，並將採取更多的資源來清除對方。

下一步vBET 3.x的版本可以幫助您 - 我們將增添新的先進的性能參數非常大的頁面。我們還發現瓶頸與鏈接的翻譯。在這一刻，我們已經實現的解決方案為 VB友好的URL vBET4.x（還沒有發布），我們將盡量採用它也為百度推廣。如果我們成功，我們將它移到也vBET 3.x的問題是，百度推廣的鏈接要求逐一與這將產生數十名谷歌的要求。因為我寫的，我們已經實現的解決方案為 VB Frinedly網址 - 我們提出延遲轉換。問題是，它與百度推廣工程外VB，翻譯後發生的，而且也不需要告訴不正確的URL來檢查實際 1
或把它的輸出。
很多細節 - 不 久我們知道一個瓶頸恰好只有當緩存沒有填寫，我們已經開始著手這個問題。

因此，在這一刻我只能勸你玩清算戰略和其他結算參數。對於其他策略：
- 如果清除緩存表是一個不殺你的服務器，然後設置更大的“高速緩存清除timelap” - 你的服務器將需要呼吸之間的空地
- Analise您的論壇流量和檢查時，少 - 改變結算執行到這個時候
- 設置較低的緩存 TTL - 較小的表將被清除，以便結算本身將需要較少的資源。另一面 - 服務器將要問谷歌更經常的翻譯。
- 實驗：設置“快速刪除與優化本地表”開放 /包括/ vbenterprisetranslator_functions.php 和註釋有3行代碼“優化當地表“。這將使真快不刪除索引升級。注意：索引會增加，所以你必須手動執行查詢 - 即每週檢查一次。如果它會為你工作，我們將實施新的戰略，其中的索引將被重組不是每天。

[tavenger5]

是在百度推廣。

我使用的正常刪除的時刻，它似乎並不需要很長時間才能得到的東西清除。憑藉快速的本地刪除的索引是留在機智，和正常刪除的索引將被清除？請問有舊索引有什麼好處，如果他們不優化？

事情似乎只是放慢時，有很多網站上的流量和緩存正在重建。我敢肯定，這是因為 Apache進程不被關閉一樣快，他們通常會（因為數據是被要求從谷歌）。

這是很好聽，未來版本將再次提高車速。我只是確保有沒有什麼我可以做調整的Apache。

[vBET]

如果您使用的是正常的結算，然後忘了我的提示。我還以為你正在使用的最後戰略和刪除整個緩存。對不起 - 誤會 剛剛離開它，因為它是。

在這種方式我可以告訴設置更大的緩存 TTL。更少的數據將被刪除，每次，所以欠的數據將被收回。
就像我寫的我們已經發現了一個瓶頸有 vBSEO + 空的快取，我們正在處理

你也可以做的是確保你的服務器沒有控股傳出請求。我們發現，一些服務器如果很多這樣的行為傳出請求都將同一台服務器。因為 100個請求可以採取更多的時間比1000 × 1的要求（100 ×理論上應該採取更多的時間）。它可以是一些防火牆，服務器安全問題。當然，谷歌可以放一些小的“懲罰”在這種情況下。所以，如果你能找到的東西在這方面 - 它可以提供幫助。如果不是請等待改進