單核 -512M內存-2000併發正常使用

自從本身創業之後就不多寫博客了，也許是太忙了。也許是沒法靜下心好好研究一個東西。今天把咱們作的後臺作了下壓力測試。結果還能夠，尤爲是對於我這種從java轉過來土人。

4年前看到一篇抨擊java的文章 《名詞王國之死》，當時很不屑，如今看來在不少場景，尤爲是能真正給用戶節省資源的地方，java真的差了很多。以前使用tomcat，一臺4g內存的服務器，死活上不了1000併發，tomcat這東西的對硬件的利用率過低了。咱們來看看ngx+nodejs

---

測試環境

機器型號：vmware 虛擬機，分配最大內存1G,分配cpu核數1核，單線程。（原始機器爲辦公電腦：i5-4690，4g內存，500G硬盤）

系統控制： pm2 設置： 內存< 256M ,production 模式。

測試工具： jmeter - 2.1.3

系統軟件： nginx , yliyun-server, mysql , reids

壓測接口： 文件列表[100個文件] ，用戶列表[100用戶]，小文件上傳（<500K）

測試步驟

循環次數：（10次）

線程數依次： 100， 500 ，1000， 1500， 2000， 2500， 3000，

測試結果展現【僅展現文件列表接口】

• 100 線程（相似100併發）

線程數設置爲100，啓動時間爲3秒，單個線程循環10次，出錯繼續（後續都是如此配置）

咱們能夠看到100併發，固然是毫無壓力，繼續。

• 500線程

ok, error% 這一欄爲0,用戶列表是另一個請求，這裏也跟着跑了10次，無視便可。

• 1000線程，過個小關

咱們看到 error 一欄代表是1000是毫無壓力的。這裏將接口返回的數據量增長到了1215.3KB,列表中顯示的數據爲30列，算是更加符合咱們正常習慣性使用。

還能夠看到應用所佔的內存從開始的(500線程)的189M上升到197M，有小幅度增長。平均數據返回爲4s，這是能接受的極限了。

所以能夠得出結論，這種配置（單核，512M內存）的機器，併發在1000左右是比較理想的。

可是咱們壓力測試不是正常使用，必須繼續，壓到出錯，或者擁有崩潰爲止。

• 1500線程

看看error,無錯經過。 看是平均延遲到了7.2s，內存使用上升到227M,這裏我在pm2 腳本設置了最大內存爲256M，"max_memory_restart": "256M",,爲了更要的壓內存，實際狀況中不推薦設置。

使用 top指令 看到 最耗內存的就是應用和msyql 數據庫了，咱們沒有數據庫列表緩存起來，緩存起來測試就顯得沒有意義了，可是實際使用中是須要開啓緩存的。

2000線程

這裏我把線程建立時間修改成5s，省得本身的機器被卡死。沒有錯誤,內存快滿了，平均延遲到達10s，對於用戶使用來講是要被吐槽的，不要緊，傻瓜才這麼用。

看看偏離，2888，看上去還不錯。

到此目的已經達到，通過咱們改造後的一粒雲的後臺（v1.1）處理能力至關優秀，固然這受益於nginx 與nodejs的異步機制。若是你有這方面的難題能夠和咱們交流。

咱們的產品官網是 www.yliyun.com，歡迎你們試用，提供邀請碼：[wymf008]。產品是免費的。客服妹子西瓜qq：2941390949。

• 2500線程 咱們還應該繼續

出錯了，5個請求出錯，日誌顯示都是超時，咱們能夠看到max這一欄超過60s了，ngx配置keeplive 時間爲60s。內存也接近250m。

• 再試試3000線程

感受上一把的0.02%的錯誤還有點小，再壓壓。

結果差很少，都是超時致使。若是還要提高的併發的話必需要加大內存才行了。

cpu 也同樣，我一路監控下來都是在82%-95%，可是nodejs 必須再多開一個進程。

好了，技術是沒有優劣沒有盡頭的，合適本身的纔是最好。