Locust 教程

寫在 Locust 教程開始的前面

本文參考了： Locust 教程；

locust 的官方 Github 是：https://github.com/locustio/l...

這個教程是我翻譯官方 Github 介紹並搜索網絡的相關 locust 使用文章而組織的教程哦；

locust 這個工具，須要根據你的實際狀況來決定是否是適合你；

若是你對編程瞭解比較多，並非只會 jmeter 的測試人員；

那麼徹底能夠代替笨拙的 jmeter 處理你的測試，它在自定義方面處理的很是好，這也就帶來一個弊端，就是什麼都須要你來作，並且對你的代碼能力和邏輯思惟有必定的要求；

若是你對 編程是一臉懵逼的狀態，那麼建議你仍是 jmeter 爲主（畢竟要幹活），而後瞭解下 Locust，看看它是怎麼工做的，瞭解下它的處理思惟；

Locust 是什麼？

Locust 是一個比較容易上手的分佈式用戶負載測試工具。

它旨在對網站（或其餘系統）進行負載測試，並肯定系統能夠處理多少個併發用戶，Jmeter 也能夠處理這種場景，可是我的感受 Jmeter 在這方面作的不如 Locust 專業。

Locust 在英文中是 蝗蟲 的意思：

做者的想法是，在測試期間，放一大羣 蝗蟲 攻擊您的網站。

固然事先是能夠用 Locust 定義每一個蝗蟲（或測試用戶）的行爲，而且經過 Web UI 實時監視圍攻過程。

這將幫助您在項目上線以前測試並肯定項目的瓶頸；

若是上線幾我的訪問就跪了，被老闆拉出去祭天就懵逼了，有了 locust 可讓項目更加快樂的上線；

Locust 可讓測試工程師對開發人員和項目經理的回覆的更專業，

能夠想象一下，當項目經理或領導問你這個項目的性能如何，能夠承受多少壓力的時候；

你回答說這個項目的瓶頸在 2341 人同時訪問，超過就會掛掉 / 宕機 / 出錯等，當在 1834 人同時訪問時候，會變慢；具體訪問時間的餅圖如 XXX）

這樣的回答是否是逼格很高？

Locust 的運行原理

Locust 的運行原理是徹底基於事件運行的，所以能夠在一臺計算機上支持數千個併發用戶。

與許多其餘基於事件的應用程序相比，它不使用回調（好比 Nodejs 就是屬於回調，Locust 不使用這種的邏輯）。

相反，它經過 gevent 使用輕量級進程。測試您站點的每一個蝗蟲實際上都在其本身的進程中運行（正確地說，是Greenlet）。

這可讓您寫 Python 代碼的時候更加簡單，而不會進入相似 JS 的那種回調地域。

我是如何開始瞭解 Locust 的

我是一名碼農，寫接口的時候，除了 Postman 作校驗外，偶爾也測測一些接口的性能；

2017 年的年中時候，作接口壓力測試，一直研究使用 jmeter 寫寫 DEMO 仍是很嗨皮的；

可是真正進行併發接口時，發現 jmeter 在單機下併發超過 1000 的時候，單臺臺式電腦機器的資源早就被使用完，jmeter 都動不了，基本就算涼了；

也多是個人 jmeter 壓測接口研究得不夠，不會用吧 - -，若是有優雅的方法，歡迎告訴我；

經過搜索發現基於 Python 開發的 Locust 的單機併發能力很理想，在測試環境拿來壓測，好像真的能夠實現幾千的併發，而後就打開了 Locust 的大門。

Locust 的 特徵

• 用 Python 編寫測試方案

  • 不須要在 UI 界面上傻乎乎的點擊，只需正常的寫寫代碼就能夠了。
  • Locust 基於協程而不是回調，這樣會讓您的代碼相似於正常的 Python 阻塞代碼那樣同步執行。

• 分佈式 & 可擴展

  • 支持模擬數十萬的用戶行爲（仍是很是給力的）
  • Locust 支持分佈在多臺計算機上的運行負載測試（能夠多臺機器並行開搞）。
  • 因爲基於事件，所以即便一個蝗蟲節點也能夠在單個過程當中處理數千個用戶。

  • 不過即便您模擬了這麼多用戶，也並不是全部人都是這種頻率的使用您的系統，一般，用戶會有思考的時候，會想想下一步該怎麼作。

    • 須要明白 每秒請求數 不等於 在線用戶數。

• 統計結果基於 Web 界面

  • Locust 有一個簡單的用戶界面，可實時顯示相關的測試詳細信息。
  • 統計結果界面是基於網頁的，而網頁是天生跨平臺的，因此 Locust 是跨平臺且易於擴展的（Locust 做者的這種思惟仍是很不錯的）。

• 能夠測試任何網頁 / 應用 / 系統

  • 即便 Locust 是面向 Web 的，它也能夠測試幾乎全部項目

  • 只需用 python 編寫想要測試的方案，而後放"蝗蟲"去懟須要測試的項目就能夠了，很是簡單！

    • 雖然官方是這麼宣傳的，可是若是你對 python 瞭解的不怎麼樣，那可能就沒有那麼簡單啊；就像商家把蘭博基尼的操做宣傳的再簡單，我沒錢買也是白搭（老鐵，我太難了！）
    • 若是你對編程是懵逼的狀態，那仍是回去用 jmeter 吧，優雅不優雅的先不說，最起碼你能夠用它來幹活；

• 容易被入侵

  • Locust 放出去的蝗蟲很小，很容易被入侵，開發團隊是一隻打算保持這種狀態的。
  • 事件 I/O 和協程的全部繁重工做都委託給 gevent
  • 團隊是看到 jmeter 等其它測試工具，處理的太 low，太死板了，因此才寫的 locust；

Locust 是徹底基於 Python

http 請求徹底是基於 requests 庫；

Locust 支持 http、https 協議，還支持測試其餘協議，websocket 等；

只要採用 Python 調用對應的庫就能夠了。

• http/https 採用 requests；
• websocket 採用 websocket ；

Locust 的創做背景

Locust之因此建立，是由於做者受夠了現有的解決方案。

做者認爲他們都沒有解決正確的問題，沒有抓住要點，簡單的講，就是做者認爲他們太 low 了，一個能打的都沒有，因而本身擼了一個 Locust 給你們用。

做者也深度嘗試過 Apache JMeter 和 偶爾用用 Tsung。

JMeter 帶有一個 UI，不少人可能會認爲這是一件好事，只須要點點就好。

可是若是你是一個測試測試，很快就會意識到，經過某些點擊界面「編碼」您的測試方案是一種 PITA。

其次，JMeter 是線程綁定的，這意味着對於每一個要模擬的用戶，都須要一個單獨的線程。這也就致使了，在一臺計算機上模擬成千上萬的用戶進行基準測試是不可行的。

另外一方面，Tsung 沒有用 Erlang 編寫的線程問題。

它能夠利用 BEAM 自身提供的輕量級工藝，而且能夠愉快地擴展規模。

可是在定義測試方案時，Tsung 和 JMeter 同樣有限。

它提供了基於 XML 的 DSL 來定義用戶在測試時的行爲方式（這種格式仍是很 low 的，可是卻很直觀）。完成後顯示任何種類的圖形或報告，都須要對測試生成的日誌文件進行後處理，只有這樣，您才能瞭解測試的進行方式。

做者在建立 locust 時試圖解決這些問題。

開源許可證

根據 MIT 許可得到許可的開放源代碼（有關詳細信息，請參閱 LICENSE 文件）。
本文參考阿西河的 locust 教程 編寫的