【51CTO.com快譯】 軟件性能和可伸縮性是我們談論應用程序開發時經常遇到的話題。一個很大的原因是應用程序的性能和可伸縮性直接影響其在市場上的成功。一個應用程序，不管它的用戶界面有多好，如果它的響應時間很慢，就不會擁有高市場份額。這就是為什么我們花這么多時間改進應用程序的性能和可伸縮性，因為它的用戶基礎在增長。

[[200759]]

日常測試失敗在哪？
幸運的是，我們有很多工具來測試高負荷條件下的軟件行為，也可以幫助識別工具性能和可擴展性存在的問題。而其他基準測試工具也可以要求測試系統在高負荷下提供系統穩定性的測試。然而，當我們嘗試使用這些工具來測試企業產品的性能時，我們遇到了性能和規模工程的問題。一般來說，這些產品不是單一的應用程序，而是由幾個不同的應用程序相互交互，以提供一致和統一的用戶體驗。

如果我們只測試它的單個組件，我們就不能獲得關于產品性能和可伸縮性問題的任何有意義的數據。只有在實際場景中測試應用程序，即把整個企業應用程序置于實際工作負載中，才能收集真實的數據。

問題是：我們如何能夠在一個測試場景實現這一現實的工作量？

容器--救援集裝箱

答案是容器。為了解釋容器如何幫助我們測試產品的性能和可伸縮性，我們來看一個軟件配置管理工具puppet。Puppet使用C5體系結構，其中有一個或多個Puppet主機（服務器），以及使用Puppet運行Puppet代理（客戶端）配置的系統。

為了理解應用程序的性能和可伸縮性，我們需要在不同系統上運行高負載的puppet-master。為此，我們可以在一個系統上安裝puppet-master，然后運行我們的操作系統的多個容器，在這里，我們安裝和運行puppet-agent。

接下來，我們需要配置puppet-agent與puppet-master進行交互，以管理系統配置。這在服務器處理請求時強調服務器，并在客戶端更新軟件配置時強調客戶機。

那么，容器在這里能起到什么作用呢？我們能不能只通過一個腳本模擬的Puppetmaster負載？答案是否定的。即使模擬了負載，我們也會對產品性能有不夠客觀的判斷。在現實生活中，除了puppet-agent或puppet-master之外，用戶系統還將運行許多其他進程，其中每個進程消耗一定數量的系統資源，因此直接通過限制puppet可以使用的資源來影響puppet的性能。

這是一個簡單的例子，但是在處理多個組件組合的產品時，企業應用程序的性能和規模工程可能會變得脆弱。這就是容器的優勢所在。

為什么是容器而不是別的？

一個真正的問題是：為什么要使用容器而不是虛擬機(VM)或僅僅是裸機？運行容器背后的邏輯與我們可以啟動的容器圖像的數量有關，還有它們相對于替代品的成本問題。

雖然VM提供了強大的機制，但它們也會占用巨大的系統資源，從而限制了可以在單個裸機服務器上復制的系統的數量。相比之下，在同一個系統上啟動1000個容器是相當容易的，這取決于您想實現什么樣的模擬，同時維持較低的開銷。

使用裸機服務器，性能和規模可以根據需要實現，但一個主要問題是成本開銷。你會購買1000臺服務器只是為了進行測試嗎？這就是為什么容器總體上提供了一種經濟的和可擴展的方法來測試產品在實際情況下的性能，同時還能保持較低的資源成本和開銷成本。

作者：SaurabhBadhwar
原文鏈接：https://opensource.com/article/17/8/containers-software-performance-and-scale
劉妮娜譯

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】