在上一篇博文里我们配置好了测试计划，接下来开始实际测试
首先关掉所有无关的软件，确保cpu和内存资源足够（我测试时cpu使用率1~2%，内存28%左右）
每次测试完都关闭jmeter，等资源释放了再重新打开，确保公平
点扫把清掉以前的测试结果，点播放按钮运行测试
测试实际上以xml - html - json的顺序交替进行，下文为了方便看把同类的截图放一起
XML
不开任何提取器
xpath
吓死人，一开吞吐率就只有原来的16.85%
（下文一律以吞吐率计算）
正则
95.78%
正则提取器胜出
HTML
不开任何提取器
css （默认使用JSOUP）
86.14%
还是css（改为使用JODD）
90.08%
xpath
21.24%
正则
94.94%
正则提取器又胜出
css在绝大多数时候也完全够用，通常也更实用些，毕竟正则表达式难看难写难维护
xpath可以拖出去砍了
JSON
不开任何提取器
json path
93.07%
正则
97.14%
正则提取器三连胜
但除非要求特别高实在没办法，一般肯定选json path，好写就是最大的优势，节约时间
结论
经过多次测试，各自的表现大致也就上面那样
css和json path提取器在各自的领域表现良好，确实有必要的时候完全可以放心用
正则提取器（至少针对这种简单的情况）性能最好，适合要求特别高的场景；复杂的情况没去试，毕竟正则写起来太烧脑，我懒……
xpath这种人人都知道慢的东西能避开就避开吧，幸好现在一般都不用xml做报文了，基本遇不上
PS：
几张图直观的看出用命令行和GUI压的差距
以下全是关掉所有后置处理器的
XML
HTML
JSON
就连最慢的xml，吞吐率都快翻了倍，json更是差不多3倍了
所以GUI只适合调试，真正去压大家都用命令行