比較ツール
主流のオープンソースのパフォーマンステストツールは、以下の主を持っています
| 比較のポイント |
JMeterの |
nGrinder |
ガトリング | 宗 | 結果 |
| オープンソース | 無料、完全にオープンソース | 無料、完全にオープンソース | 無料、完全にオープンソース | 無料、完全にオープンソース | = |
| 実装言語 |
JAVA |
JAVA |
Scalaで書かれた、Javaライブラリをサポートしています | アーラン | JMeterの= ngrinder>ガトリング>宗 |
| 使用 |
C / Sまたはコマンド |
B / S |
コマンド | コマンド | = |
| 分散型のサポート |
マスタ/スレーブ |
コントローラ/エージェント |
サポートしていません。 | マスタ/スレーブ | JMeterの= ngrinder =宗>ガトリング |
| リソース監視 |
モニター/プラグイン |
モニタモードでは、可能な直接ソースがあります |
ノー | アーランまたはSNMPプロトコルは、リモートマシンを監視し、対応するグラフを生成するために使用することができます | JMeterの= ngrinder =宗>ガトリング |
| コミュニティ活動 |
完璧なドキュメント、マルチユーザー |
中国のコミュニティがあります。 |
コミュニティをサポートしています | コミュニティをサポートしています | JMeterの= ngrinder>ガトリング>宗 |
| コーディングの必要性 |
基本的な必要性 |
ニーズ、Jythonの/ Groovyの |
ニーズ、スカラ | 必要 | JMeterの>宗> ngrinder =ガトリング |
| メンテナンススクリプト |
ローカル |
内蔵SVN |
ローカル | ローカル | = |
| スクリプトの記録 |
サポートHTTPプロキシ記録、サードパーティ製のレコードのサポート |
プラグインは、PTSにより記録することができます |
サポートHTTPプロキシ記録 | レコードサポートスクリプト | = |
| 使いやすさ | 成熟したテンプレートは、コンポーネントは、直接導入コントローラは、低プログラミング要件を使用することは比較的容易です | 制御ロジック、パラメータ化、チェックポイント依存のプログラミング | Scalaのあまり慣れている人、ロジック制御、パラメータ、依存チェックポイントプログラミング | このスクリプトは、同じフォーマットとLoadRunnerのです | JMeterの>宗> ngrinder>ガトリング |
| プロトコルのサポート | マルチプロトコルサポート | httpプロトコル、他の人が自分の拡張機能を開発する必要があります | httpプロトコル、他の人が自分の拡張機能を開発する必要があります | マルチプロトコルサポート | JMeterの>宗> ngrinder>ガトリング |
| スケーラビリティ |
プラグイン、および強力な拡張を増やします |
プラグインをサポート |
機能を拡張しやすいオープンソースのセットに基づいてAPTガトリングDSL、 | プラグインをサポート | = |
| インストール |
あるコピーとベースのJDK、絶対的な軽量、 |
2つのサービス・コントローラとエージェント |
あるコピーとベースのJDK、絶対的な軽量、 | あなたは、3つのサービスをインストールして設定する必要があります | JMeterの=ガトリング> ngrinder>宗 |
| 圧力測定プラットフォームの符号量 | すばらしいです | 小さな | すばらしいです | すばらしいです | ngrinder> JMeterの>ガトリング=宗 |
通过从下面各个维度对比可以看出，工具jmeter都具有优势，但压测平台的开发编码量比较大，nGrinder有现成的压测平台，开发工作量少，但是易用性不如jmeter，脚本需要大量的编码工作，推广难道比较大，两者各有优缺点。
平台开发工作量对比
如下为完全平台化需要完成的核心功能点
| 比较点 |
JMETER |
nGrinder |
| 平台开发主要实现功能 | 核心功能点如下
|
核心功能如下
|
可以看出JMETER的工作量要远大于nGrinder
易用性对比
在易用性主要是在脚本的编码工作量方面，通过对比可以看出jmeter无非常明显的优势，前提是测试人员具备一定的编码能力
| 比较点 |
JMETER |
nGrinder |
| 参数化 | 通过界面操作完成，简单 | 需要手功编写代码，编码工作量少，简单 |
| 关联 | 界面操作，各个接口之间的数据可以直接传递，简单 | 各个方法之间的值可以直接传递，简单 |
| 检查点 | 界面操作完成，简单 | 有检查点的方法调用，简单 |
| 综合场景 | 有丰富的逻辑控制器，简单 | 需要大量的编码工作，复杂 |
压力机硬件资源消耗对比
压力机对资源的占用对比，已压测某服务为例，使用相同的并发用户数500，对比压力机资源占用可以看出，ngrinder的cpu占用是jmeter的4倍，内存占用是jmeter5倍
| 比较点 |
JMETER |
nGrinder |
| cpu | jmeter只需要1个进程，cpu占用为320% |
agent 如下10个进程CPU占用达到1200%
|
| 内存 | 进程内存占用为0.96G | agent10个进程内存占用5.3G |
nGrinder 压测时，监控agent资源利用情况
jmeter
测试指标对比
通过对同一服务，相同并发数和测试时间，对比业务指标TPS和平均响应时间结果如下，jmeter的值要远大于nGrinder，后续我们对nGrinder的压测节点进行扩容
最终也只能压测到18000多TPS
| 比较点 |
JMETER |
nGrinder |
| TPS | 24002 |
14778 |
| 响应时间 | 20ms | 33.1ms |
nGrinder测试结果截图
JMETER 测试结果截图
综合分析
在工具对比方面，jmeter最具优越性，而且目前公司的性能测试都是用jmeter工具，免去替换成平台后需要重新编写测试脚本的问题，nGrinder在平台二次开发上最简单，在易用性方面也比较好（前提是要具备一定的编码能力），但是在调研的过程中发现非常耗压力机资源，在相同并发下cpu占用是jmeter的4倍，内存占用是jmeter5倍以上，同时在测试kong的时候发现无法压测到kong的极限值。所以最终推荐压测平台使用集成jmeter的方式。