摘要：
性能測試是準許任何軟體産品出廠之前要執行的重要過程。您可能已經聽過進階同僚的一些恐怖故事，這些故事是關于系統出廠時沒有任何性能測試的。是以，現在，這是測試的必要部分。有多種工具可用于實作非GUI中間件系統的性能測試，但是有時候我們沒有自由選擇現有的一組性能測試工具。
性能測試是準許任何軟體産品出廠之前要執行的重要過程。您可能已經聽過進階同僚的一些恐怖故事，這些故事是關于系統出廠時未經任何性能測試的。是以，現在，這是測試的必要部分。有多種工具可用于實作非GUI中間件系統的性能測試，但有時我們沒有自由選擇現有的一組性能測試工具。
性能測試是準許任何軟體産品出廠之前要執行的重要過程。您可能已經聽過進階同僚的一些恐怖故事，這些故事是關于系統出廠時未經任何性能測試的。是以，現在，這是測試的必要部分。有多種工具可用于實作非GUI中間件系統的性能測試，但有時我們沒有自由選擇現有的一組性能測試工具。
為什麼不選擇現有工具？
以下是一些原因使我們無法選擇市場上已有的工具。
該工具中沒有合适的請求觸發選項。有些中間件系統具有自己的性能要求，而商用工具無法完全滿足它們。例如，我使用的電信服務傳遞平台正在使用Sigtran協定。很難找到一種支援該協定的性能工具。典型的性能工具不支援其他一些協定，例如通用計算機協定和計算機與消息的互動。如果現有工具不支援我們重要的性能要求，我們可能會被迫選擇自定義性能工具。
測試工具的性能可能不足。商業工具可能具有許多功能，但是并非所有功能在任何給定時間都是有用的。由于這些額外功能，性能工具可能無法達到預期的水準。我們可能也抱有更高的期望：以較高的速率觸發請求，例如每秒2000個事務（TPS），并使用較低的系統資源（記憶體，CPU，I / O）。
當工具提供更多功能時，它們可能還會使用更多系統資源。這些商業工具通常建議從多台機器觸發以實作每秒更高的請求數量，但這會增加項目成本。如果我們更關注較高的觸發性能要求和較低的系統資源使用量，則可能必須建構自己的工具才能以較高的TPS有效觸發。
該工具在商業上不可行。一些工具可能提供了足夠的選擇，但是價格可能無法幫助我們将成本控制在項目預算之内。有時候，花錢買工具可能不值得。免費的開源工具可能無法提供足夠的功能。建構我們自己的性能工具也不是免費的。我們可能必須估算建構自己的工具的成本，然後将使用現有工具的成本進行比較以做出決定。
在我們公司中，我們使用了一些與電信相關的協定，但找不到合适的工具。我們最終自己建構了性能工具。一旦成功，我們便開始為大多數項目實施該工具。
建立自己的績效工具的優勢
由于上述一個或多個原因，我們可能被迫編寫自己的工具來進行性能測試。這給了我們更多自由來決定如何設計性能工具以及包括哪些功能。以下是建構自己的定制工具的一些優點。
我們可以自由地增強性能測試工具的功能。如果選擇現有工具，那麼我們将受限于該工具的功能。例如，我們可能選擇适合大多數情況的最合适的工具。但是，如果幾個月後我們收到客戶關于随機響應延遲的投訴，那麼我們将不得不衡量這些随機延遲。如果我們選擇的工具不支援此功能，那麼我們可能必須尋找另一種方法來進行測量。但是，如果我們擁有自己的工具，則可以更輕松地擴充工具的範圍以支援此類新要求。
我們可以重用現有的監視工具，而不是在我們的工具中建立監視支援。作業系統通常會提供足夠的監視工具來監視系統的資源，例如記憶體，伺服器負載和CPU。此外，Java有足夠的工具，例如Flight Recorder，GC日志，Jstack和Jconsole，是以我們可以利用這些現有工具來補充我們自己的性能工具。我們可能必須建構簡單的請求觸發工具，并且為了進行監視，我們可以使用這些現有工具。
我們可以建構可重用的績效工具來證明業務決策的合理性。作為一個組織，我們可能有幾種類似的産品，如果我們建構可重用的工具，它将有助于在業務級别證明我們的決定的合理性。作為技術人員，建構工具很有趣。在注意并發問題的同時，将需要具備編寫良好代碼的專業知識。如果我們可以将該工具重複用于各種項目，則可以幫助我們降低組織的成本。
我們可以成為使用JDK和基于作業系統的監視工具的專家。如果我們使用JDK和基于作業系統的工具進行性能監視，則可以成為使用它們的專家。以後，這些經驗在監視生産系統中的性能問題時會很有用。99％的時間将不允許您使用性能軟體進行安裝和監視，因為這可能會導緻安全問題，并可能增加生産流量的開銷。是以，最好具有這些基本系統和JDK工具的專業知識，這些知識可以始終幫助您解決生産性能問題。
建構自己的性能工具的缺點
認真分析編寫自己的工具的需求非常重要。通常，建議将完善的工具重新用于典型的性能測試，但是也有例外。在決定編寫自己的工具之前，強烈建議進行清晰的分析。這是建構自己的性能工具的一些缺點。
建構該工具将需要大量的專業知識和知識。您可能需要大量的專業知識才能編寫出可以滿足您期望的好的工具。以下幾點至關重要：并發，有效的連接配接處理和有效的記憶體使用。如果您的團隊缺乏對所需技術的深入了解，則不建議自己使用工具。
建立工具可能很昂貴。如果未進行正确的估算，則最終可能會花費更多，而不僅僅是購買現成的工具。建議在決定編寫自己的工具之前進行正确的分析和估計。
性能工具本身的性能問題很危險。這是典型的“誰看守守望者”問題。如果您的工具不幹淨，則可能會錯誤地懷疑已經過性能測試的系統。是以，需要對您的工具進行适當的性能檢查。
您準備自己的表演太準則升
以下是一些有關準備自己的性能工具的建議指南。
明确定義性能工具的範圍。首先，我們需要選擇性能工具的範圍。範圍可以取決于這些選項。
- 請求觸發能力-該工具需要支援每秒不同數量的事務，因為某些系統可能以基于類似圖形的模式或恒定模式的模式擷取請求流量。如果需要依賴于先前觸發的請求響應的請求，我們可能必須緩存每個請求的響應值。
- 運作該工具的可用資源-根據資源限制，我們可能必須調整此性能工具才能有效地工作。需要考慮記憶體和CPU使用率。
- 如何進行性能監視-我們是否将依靠該工具通過記錄系統使用情況詳細資訊來進行性能監視？
選擇簡單有效的技術。選擇一種更簡單的技術以確定任何人都可以開發和更改它很重要。如果我們對此觸發工具沒有太多複雜的要求，我們甚至可以使用簡單的腳本語言。
確定該工具使用最少的系統資源。該工具不應執行任何不必要的計算或不必要的日志記錄。它應該做最少的活動以確定它使用更少的資源，并且可以在較低的系統資源使用率下以最高的速度執行。
是以，最重要的是，根據項目的性質，您可以編寫自己的性能工具，但是我隻建議這種方法用于沒有合适的性能測試工具的高端中間件系統。