自從自己創業以后就很少寫博客了，也許是太忙了。也許是無法靜下心好好研究一個東西。今天把我們做的后台做了下壓力測試。結果還可以，尤其是對於我這種從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 必須再多開一個進程。
好了，技術是沒有優劣沒有盡頭的，合適自己的才是最好。