扼殺伺服器效能的10條戒律(3)

來源:互聯網
上載者:User
伺服器|效能 不要進行測量

當你能夠測量你所談論的事情並用數字表達它時,這就表示你對他有了一定的瞭解;但是如果你不能用數字表達時,你的知識是貧瘠的不能令人滿意的;這可能是知識的開始,但這時你簡直不可能將你的思想提高到科學的水平。
- Lord Kelvin (William Thomson)

如果不測量你就不能瞭解應用程式的特性。你在黑暗中摸索,一半是靠猜測。如果不識別效能問題,你就不能做任何改進或做出工作量計劃。

測量包括黑匣子測量和profiling。黑匣子測量的意思是收集由效能計數器(記憶體使用量,上下文交換,CPU利用等)和外部偵查工具(通量,反映時間等)所顯示的資料。為了profile你的代碼,你編譯代碼的一個工具版,然後在各種條件下運行它,並收集關於執行時間和程序呼叫頻率的統計資料。

測量如果不用於分析的話就一點用都沒有。測量將不僅告訴你有問題,而且甚至能協助你找到問題發生在哪,但它不能告訴你為什麼會有問題。對問題進行分析以便你能正確地改正他們。要從根本上解決問題而不是停留在表面現象。

當你進行改動後,要重新測量。你要知道你的改動是否有效。改動也可能會暴露其他效能問題,測量-分析-改正-再測量的迴圈就會重新開始。你也必須要有規律地進行測量,以便發現效能衰退問題。

應該使用單一使用者,單一請求的測試方法。

書寫ASP和ISAPI應用程式的一個通病是只用一個瀏覽器去測試應用程式。當他們在Internet上應用他們的程式時,他們才發現他們的應用程式不能處理高負載,並且通量和反應時間另人可憐。

用一個瀏覽器測試是必要的但是不夠的。如果瀏覽器反應得不夠快,你就知道你有麻煩了。但即使它在使用一個瀏覽器時很快,你也不知道它處理負載的能力如何。如果十幾個使用者同時請求會發生什麼事?一百個呢?你的應用程式能容忍什麼樣的通量?它能提供什麼樣的反應時間?在輕載時這些數字會怎樣?中等負載呢?重載呢?在多處理器機器上你的應用程式會如何?對你的應用程式進行強度測試,這對於找出bugs發現效能問題來說是基本的。

類似的負載測試考慮適用於所有的伺服器應用程式。

不應使用實際環境。

人們往往只在幾個特定的,人工的環境(如下benchmarks)下調整應用程式。選擇和實際情況相對應的各種情況,並為針對各種操作進行最佳化,這一點很重要。如果你不這樣做,你的使用者和評論家一定會這樣做,並且他們將依此來評判你的應用程式的好壞。
結論

自從我們開始開發IIS以來,我們已經對扼殺伺服器效能和伸縮性有了一定的瞭解。書寫高效能的伺服器應用程式是不容易的。除了在書寫傳統型應用程式時遇到的傳統問題外,你必須特別注意記憶體配置,緩衝列,快取資料,線程原型化,加鎖策略,多處理器機器,模組化調用,測量和分析,多使用者測試,和實際環境的問題。這些問題可能會造就你也可能毀了你。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。