一句話結論
對于跑在單核CPU上的運算類API, 根據業務需求(最大響應時間)來調試找到最大線程數,然后依據線程數調試出heap大?。ㄖ饕茨昀洗幕厥沾螖担?/p>
若有理解不到位之處,請在評論區留言,跪謝!
背景
斷斷續續忙碌了幾個月,終于自己寫的開源項目算是有了雛形,打包成Docker image發布到AWS EC2后,寫代碼算是告一段落。隨之而來的問題就是“我的項目能夠支撐多少QPS” ,由于用了Docker, 即變成了“我的項目基于Docker的配置能夠支撐多少QPS”, 更進一步細化這個問題的話,有以下幾點:
說句題外話,我認為按照服務商提供的最小單元來劃分的好處在于:減少開銷。500M的費用只有1G的一半,而且將來項目動態伸縮的靈活度高,粒度更小。
俗話說的好, 拋開業務需求來談IT就是耍流氓。
項目是開源項目,業務需求那就只好我自己定了,一般來說我們并不希望用戶登錄過快(并且并發登錄的情況雖然有但是確實比較少見),這次的api (oauth/token) 我定在了2秒的最大值,以此為基礎來找出性能瓶頸。
那么在不改動項目代碼的前提下,可以調整哪些參數來提升性能的呢?
對于計算為主的項目,主要關注點還是在max-threads,設置合理的話可以減少CPU上下文切換帶來的性能開銷,以及合適的Heap大小來避免頻繁觸發GC所造成性能抖動。
雖然標題是基于Docker的性能測試,但是我還是想對比一下用與不用Docker上的性能差異,所以測試會分為兩個部分, 以下為jre的基本信息
ubuntu@ip-xxx-xx-xx-xxx:~$ java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed mode, sharing)復制代碼
ubuntu jre 信息
/ # java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)復制代碼
docker jre 信息
3.1.1 Heap 固定,不同線程數關系圖
50m Heap大小在100個線程的情況下OOM,所以這里為0
3.1.2 線程數固定,不同Heap大小下關系圖
直接上對比圖
上圖為不限制Docker 容器大小的結果
上圖限制了Docker 容器大小為450M
上圖100 threads 50m Heap 的時候程序直接崩潰了所以為0
很明顯,Docker會帶來一定的性能開銷,并且隨著線程數的增加與QPS的增加,這種開銷會更加明顯。但是并不是說Docker不好,畢竟性能開銷只要多開一個節點就搞定,和Docker帶來的便利性相比,幾乎可以無視。
這里的討論僅限于單核CPU負載較高的運算類API,Serial GC
對于跑在單核CPU上的運算類API, 根據業務需求(最大響應時間)來調試找到最大線程數,然后依據線程數調試出heap大?。ㄖ饕茨昀洗幕厥沾螖担?/p>
很簡單,10 threads 100m heap
原文轉自:https://juejin.im/post/5d4cd38cf265da03b120394c