Share via


Windows 機密 就近緩存原則

Raymond Chen

緩存可以改進性能,但您必須正確使用它們。 通常,您可以嘗試很多參數,但是即使準確調整了緩存策略,仍需要正確使用緩存。

以下是一個實際事件示例。 我已將此示例改寫為讀者比較容易理解的語言,這樣,我就不用費力解釋與主要問題無關的技術詳情。

假設紐約的一家公司擁有一台中央 Web 伺服器,用作文檔檔案。 該公司可能做出如下請求:請查找我們在 2005 年 6 月 23 日歸檔的 Johnson 案例上訴駁回的訴狀。 這實際上是一個靜態網頁,文檔不會更改 — 如果訴狀需要更新,將歸檔所做修訂;由於原始文檔已歸檔,所以仍舊保持不變。 除非存在時間機器,才能通過時光倒流的方法更改原始訴狀。 (如果他們真的獲得這樣一台機器,則他們所做的一些看似無足輕重事情,可能會在不經意間改變了人類歷史)。

這與緩存 Web 代理伺服器的使用模式相對應。 如果有人請求過 6 月 23 日的訴狀,不久另一人請求相同的文檔,此時代理伺服器可以使用第一次查詢的結果來回應第二次查詢,而不用重新返回到中央伺服器。

假設此公司已擁有一台緩存 Web 代理伺服器,並對邁阿密辦公室進行了配置以便利用此伺服器。 但是性能方面並沒有改進。 即使依次向該代理伺服器多次請求同一文檔,回應的速度和直接向中央伺服器請求文檔的速度一樣慢。 問題出在什麼地方?代理伺服器損壞了嗎?

事實上,代理伺服器運行很正常。 問題出在代理伺服器所在的位置上:邁阿密辦公室與紐約的連線速度很慢,其當前使用的是安裝在紐約辦公室的緩存 Web 代理。

圖 1 中的圖表清楚地說明了為什麼使用該代理伺服器根本不能提高速度。 即使該代理伺服器工作非常順暢,而且每個請求不必傳送到中央伺服器就能得到回應,文檔仍需要通過邁阿密和紐約之間的緩慢連接進行傳輸。

fig01.gif

圖 1 代理伺服器位於緩慢連接的錯誤一端(按一下圖像可查看大圖)

如果要使用緩存,則該緩存的速度應比其緩存內容的速度快。 就此示例講,從邁阿密辦公室連接到代理伺服器的速度應比從邁阿密辦公室到中央伺服器的連線速度快。 代理伺服器的安裝位置必須靠近邁阿密辦公室。 要獲得最佳效果,代理伺服器應該安裝在邁阿密,如圖 2 所示。

fig02.gif

圖 2 對邁阿密辦公室更加有用的代理安裝(按一下圖像以查看大圖)

將代理伺服器安裝在邁阿密後,當邁阿密的律師想要調出 6 月 23 日的訴狀時,該請求將傳送到本地代理,它可以快速地從其緩存中取出相應文檔。 如果該文檔未在緩存中,則從伺服器中檢索出此文檔後,會對其進行緩存,以供下次邁阿密辦公室的人員請求時使用。

緩存利用的是臨時位置,但將代理移動到邁阿密辦公室還涉及到地理位置:邁阿密辦公室的律師希望請求與紐約辦公室律師不一樣的文檔(原因很簡單,他們處理不同的案例),此時如果針對每個遠端辦公室都具有不同的緩存,則這些緩存會為其分配給的辦公室提供更好的服務。

該組織在邁阿密辦公室安裝了代理伺服器,並將辦公室內的電腦配置為使用本地代理。 現在他們對性能方面非常滿意。

Raymond Chen 的網站 舊事新談及其同名著作(Addison-Wesley,2007 年)都探討了 Windows 的歷史和 Win32 程式設計方面的內容。 方法真的很重要。