nGrinder可以使用Tomcat服务器作为载体，用于搭建一个测试Web API压力承受能力的工具。
不过这次搭建nGrinder可谓颇费周折。
1、先从github得到nGrinder的war包，然后直接在Tomcat里面部署
这是最简单的方法，https://github.com/naver/ngrinder/releases，这里提供war包下载。然而！这里的war包下不了！可能跟我电脑有关？可是我搭了个梯子都下不了啊。。无奈。。
2、百度了一下nGrinder的war包，居然SourceForge有得下！太好了，赶紧下了一个。咦？是3.3的版本，当时github的nGrinder官网是3.4哦，就差了0.1个版本，不管了，上吧，于是拷到Tomcat的webapps里面，启动Tomcat，老是报一个数组 越界的错误（java.lang.ArrayIndexOutOfBoundsException: 29766），而且访问相应路径得到的回应是Tomcat的404！怎么回事？传送门，“Current ngrinder 3.3 does not support java 1.8. Java 1.8 will be supported in ngrinder 3.4.”kao，我装的是JDK1.9，完了，3.3不支持。
3、我尝试着下载JDK1.7，可是Oracle贼恶心要注册登录，我最讨厌了，所以不下载JDK1.7了，狠下心来，下载nGrinder3.4的war包吧。。。可是，下载不下来啊！！没办法了，背水一战，自己编一个吧！留意到github在war包下载的位置下面还有一个源码的下载链接。
4、不用梯子也很快，源码下载下来了，7兆不到，跟war包的接近70兆真是差别好大啊，看来有很多包要下载啊！先解压下载下来的zip包，得到nGrinder的文件夹，开源软件真好，什么都不瞒你，一看就知道是Maven项目，而且框架都是Spring的，eclipse什么的导入走起！
5、然后又发现eclipse打不开了，说JDK1.8找不到，回想起来是升级到1.9的时候把1.8卸载了。。。以后没事别卸载Java的环境。好吧，一顿瞎闹腾发现eclipse的运行程序同级目录有个eclipse.ini，这不就是个配置文件嘛，进去把Java环境改好，eclipse得了。
6、轻车熟路，导入nGrinder的Maven项目，结果发现是分成了好几个项目的，每个的dependency都没solve，然后就直接使用Maven update project更新项目并下载依赖包，结果发现eclipse默认的国外Maven贼慢了，十几kb的龟速。。。
7、百度eclipse使用阿里Maven，在eclipse使用的Maven配置文件中增加阿里Maven的镜像，这下下载依赖jar包速度真是非一般，两三分钟就刷完了，结果。。。每个项目还是有错误！展开项目检查发现，主项目和controller里面都有一些依赖包没有，主项目中有一个这样的错误：The POM for grinder:grinder-patch:jar:3.9.1-patch is missing，传送门，就是说要运行一个叫install_maven_lib.bat的文件（Windows下）。
8、老天保佑，在项目文件夹中找到这个文件，可以更新项目（其实就是获得这个3.9.1的patch），打开命令窗口来运行这个bat文件，等待下载完毕，会自动解压并更新这个jar包，这时感觉离成功越来越近了。
9、回到主项目中，3.9.1-patch的依赖已经解决，但是还有controller等项目的两三个依赖没解决，尽管重复使用Maven update project，依然不能解决依赖缺失。这时，我大胆猜想是阿里的Maven服务器没有包含所有的jar包导致有些jar包Maven找不到，毕竟国内的Maven库镜像，难以达到国外的完整度。然后注释掉阿里的镜像配置信息，Maven更新，果然，开始以缓慢的速度下载缺失的依赖包了！
10、漫长的等待之后，最后的两三个缺失的包都找到了，此时有些项目中的pom还是报错，但是那个不是缺失依赖包，而是其他本项目的互相依赖，感觉是编译器自己乱提示，不管了，大胆地导出war包吧。
11、最终拿3.4的代码编译出war包，也没报什么错。放Tomcat中跑起，启动期间没有报错，访问本地的相应的项目路径。成了！出现了期盼已久的nGrinder的页面！
小结nGrinder的搭建环节的坑：
1、尽量用新版的nGrinder
2、nGrinder 3.4之前的版本不支持JDK1.8及以上
3、国内的Maven服务器很可能有些包没有收录
4、有个3.9.1-patch的依赖需要运行项目脚本，下载zip包并自动解压得到
5、nGrinder在Tomcat中运行是有JVM环境变量优化环节的，具体自行百度nGrinder的部署
下次再写一篇nGrinder的学习使用篇。
=====5月6日更新=====
虽然nGrinder是跑起来了，但是新建测试后Agent一栏竟然max是0，结果无法开始测试，所以这又有什么坑吧。。。
总是觉得项目里面还是有些编译错误，我把Maven换成了3.5的版本，又不断地更换repository的源，才勉强将所有的依赖都同步下来。
查了很多资料，发现nGrinder的测试需要另外跑一些Agent才能模拟多用户并发访问，能查到的资料都说右上角的选项中download agent就可以下载下来部署了，我也下载了，可是解压后发现里面就只有一个config配置文件和一个lib文件夹，啥都没有。这时候，可以查看nGrinder的log文件（C:\Users\{用户名}\.ngrinder\logs），看看日志里面报的啥错。
日志里面说找不到dependency.txt文件（Error while loading dependencies.txt），然后去源码那里看了AgentPackageService.java在getDependentLibs方法里面有读取资源文件夹下面的这个txt，然而编译的包里面没有啊，rilegoule，上github源码里面看，也没有啊。猜想这是作者的bug吧，依赖说明文件故意不提供。
神奇地我在ngrinder-sh项目中看到一堆shell文件，猜想这些就是agent启动的批处理文件吧，于是拷到解压出来的ngrinder-agent目录下（该目录下有config文件），然后开始边运行run_agent.bat文件，边通过提示的NoClassFound错误提示逐个在项目的lib文件夹中将jar包拷到agent的lib下，已知的必须jar是asm-3.3.1.jar、commons-*.jar、dnsjava-2.1.1.jar、grinder-*.jar、jcommander-1.32.jar、jsch.*.jar、jython-standalone-2.5.3.jar、ngrinder-*.jar、picocontainer-2.13.6.jar、sigar-1.6.4.jar、sigar-native-1.0.jar、slf4j-api-1.6.4.jar、hamcrest-all-1.1.jar、junit-4.11.jar，如果导入后还是有找不到类的请继续在lib里面寻找导入，只有junit4.11的jar是从别的地方下载的。
运行run_agent.bat文件的时候我还碰到一个坑，就是有个sun.inet.spi.xxx的依赖怎么都解决不了，没想到是agent里面才报的错，谷歌了一下，才发现这玩意是java1.8的，气死老子了，只好哼哧哼哧地把jdk1.8又下载下来安装，把java环境切换回去1.8，然后删除部署的war包，将eclipse的环境切换回去jdk1.8，重新编译项目，这时候项目没有任何错误了，重新打war包，重新部署到Tomcat。注意！重新打war包之后，要将agent依赖的jar包重新重Tomcat中解压的项目的lib里面复制并替换掉agent里面的lib进行更新！
以上操作都做完了，终于看到agent没有报错地启动了，新建nGrinder的测试，终于看到agent那一栏不再是0而是1了（因为只 部署了1个agent，这里可以考虑将agent的文件夹复制多份，跑多个agent，就可以轻松搭建分布式的压力测试系统了），然后就可以跑自己的API的压力测试了。填了太多的坑，不容易。
小结这次填的坑：
1、项目其实缺少了dependencies.txt这个文件，可能是个bug
2、通过批处理文件的运行提示错误补充依赖包（这些依赖本来写在了dependencies.txt文件里面，并用分号隔开的）
3、Maven编译的不要用eclipse自带的Maven插件，core和runtime那两个项目用自带的Maven插件总是编译有错，但是如果遇到找不到的包还是要用自带的Maven结合默认的库源 下载下来
4、nGrinder不支持jdk1.9（inet那个包在1.9的路径被改了，nGrinder会一直提示找不到）
5、Junit的jar包是别的地方下载下来的