《企業網D1Net》10月13日訊
長期以來，人們一直說應用程序的性能有四大支柱：
1.記憶；2.CPU；3.網絡；4.存儲。
只要你在對應用程序的響應時間做出反應，解決了其中一個問題時，另一個就成為了瓶頸，即使你并沒有觸及這個瓶頸。
更詳細一點說，他們是：
“內存消耗”——因為在現代操作系統中，這會影響交換。
“CPU利用率”——因為無論什么操作系統，在某性能極端下降后都有一個神奇的線。
“網絡吞吐量”——因為應用程序必須通過網絡進行通信，而不論阻止與否（今天幾乎所有的網絡編碼），網絡上所要求的信息是必要的，并最終將限制代碼塊繼續執行。
“存儲”——因為在從磁盤中讀/寫、或讀/寫到磁盤中時（或在OS轉換出/回記憶時），IOPS很重要。
這四個相對比較容易跟蹤。這種關系是非常容易發現的，當你解決了一個問題，另外一個卻成為對應用程序的性能來說“最危險”的。但是，從歷史上看，你總是有權訪問硬件。即使在高度虛擬化的環境中，這些項目可以被認為是在主機和客戶機的水平——因為單個虛擬機和整個系統都很重要。
當移動到云中，四大支柱變得遠遠沒有那么易于管理了。“遠遠”所指的程度，在很大程度上取決于你的云供應商，以及你如何定義“云”。
把簡單來說，如果你突然受襲擊導致失明在你面前的景物并沒有什么變化，變化的只是你感知它們的能力。
在PaaS的世界中，你只有供應商提供的工具來衡量這些東西，且被敦促不要考慮主機可能對你的應用產生的影響。但它們確實有影響。在IaaS的世界，你或多或找會有更深入地了解，但正如其他人所指出的，比在你的數據中心的控制要少。
在SaaS的世界里，假設包括在“云”中，你有零位控制，且沒什么了解。如果你的應用程序不執行，你必須跟供應商的員工交涉（但愿如此）讓他們解決問題。
但這個問題在云中會比在數據中心更糟嗎？我會認為沒有。你的感受能力、觸摸能力下降了，但實際問題并沒有變少。在一個單一業務公共云部署中，應用程序的性能在很大程度上取決于供應商，但頂級供應商（如亞馬遜）備份，會根據需要制造副本來減少工作負載。這與一個在高度虛擬化環境中常見的表現技巧相去并不甚遠——帶來了另一臺服務器上的另一個虛擬機，并把它們添加到負載均衡。如果應用程序設計不當，最終的結果不是你購買服務器到主機實體，而是說，而是你直接購買實體。
這對IT有影響。降低使用低效應用程序的前期成本——無論它在四大支柱中的哪個方面低效——意味著IT部門更容易忍受效率低下，即使在長期運行上每月支付成本可能遠遠比購買一臺新服務器的成本高，僅僅是因為預算疼痛的減少。
有很多公司提供云部署的信息，可以幫助你確認自己是否覺得盲目。
雖然了解并不總是與采取行動直接相關，有一些只有云服務提供商可以為您提供的信息，知道的性能瓶頸在哪里至少能提供給IT人員一定程度的決策制定依據。如果一個應用程序執行不佳，調查一下出現了什么問題（你可以告訴說是網絡帶寬，虛擬機CPU使用情況，虛擬機IOPS等，但不包括發生在物理硬件上的問題）可以令決策制定知道如何將云運營成本包含在內。
內部云是一個更容易的東西，你仍然有機會獲得云出現之前的所有信息，一般情況下，是使用與高度虛擬化的環境中相類似的調查。從解決性能問題的角度來看，這是大致相同的。虛擬化和內部（私有）云的關鍵是，你意圖最大限度地利用資源，所以你將不得不更密切地觀察這些瓶頸——你處于離性能問題更近的“邊緣”，因為你就是這樣設計它的。
在云計算和虛擬化環境中，一個全面的日志和監控環境，可以在保持突然出現的問題方面走很遠——尤其是在運行著許多應用程序的大型數據中心。
對于內部開發的應用來說，對內部開發人員進行怎樣才能不耗費資源的教育是很有用的。對于外部開發的應用程序，你能做的最好的事就是要求尺寸信息，并在購買前測試他們的假設。
有時候，云實在是正確的選擇。例如，如果網絡帶寬是主要的限制因素，且你的組織這些可感知的安全/合規風險，那么云計算是一個簡單的解決方案——在云中帶寬是不受限的，或者被你每月寫支票繳費的意愿而限制。無論哪種方式，它不是一個極端昂貴的互聯網連接升級。
堅持獲取你需要的能見度，不用擔心那些你并不需要的東西。
京公網安備 11010502049343號