分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net
nGrinder是一个用于在多台机器上运行用Jython（在JVM上运行的Python）编写的测试脚本的应用程序。它的内部引擎是基于Grinder。nGrinder分别用控制器和Agent将Grinder的控制台和Agent包装起来，并扩展了支持多个并发测试的特性。
nGrinder系统架构
nGrinder由两个主要组件组成：
- Controller－为性能测试提供Web界面；协调测试过程；整理和显示测试统计数据；让用户创建和修改脚本。
- Agent－在代理模式下运行时，运行将负载放到目标机器上的进程和线程；在监视器模式下运行时，监视目标系统性能。
当启动代理时，它们尝试连接到控制器。然后它们被附加到AgentControllerServer组件中。AgentControllerServer（类似于代理池）管理当前代理池。每当用户启动性能测试时，就会创建一个新的控制台来协调代理，并从AgentControllerServer移交所需的代理数量。控制台（命名为SingleConsole，以区别于Grinder）将测试脚本和测试资源发送给多个分配的代理，并开始控制测试流，直到测试结束。测试完成后，使用的代理将返回给AgentControllerServer，稍后在其他测试中使用。SingleConsole同样也返回给ConsoleManager。
nGrinder与Grinder最大的区别在于nGrinder在控制器中保留了多个控制台实例和代理。每个控制台独立于其他控制台，所有控制台都可以并发运行。许多代理可以预先添加，并且可以在需要时进行分配。与Grinder不同，nGrinder的开发目的是最大化对Agent机器的利用率。
众所周知的负载测试工具，如“Performance Center”，都有一个测试保留特性，可以在用户开始测试时保证代理的可用性。但是保留方法会导致代理使用问题。我们观察到，人们倾向于为预防而准备代理，即使他们实际上并没有进行测试。根据我们的经验，平均代理CPU利用率不足10%。出于这个原因，nGrinder支持多重测试和动态代理分配，因此只有在执行真正的测试时，才会动态地将代理分配给测试。这使得nGrinder成为所有竞争者中唯一的解决方案。由于代理的数量相对较少，多个用户可以同时运行多个测试，并发测试的数量取决于自由代理的数量。
nGrinder集群架构
从nGrinder 3.1版本中，引入了nGrinder控制器集群，使性能测试可以由其中一个集群控制器执行，并支持使用多组代理（命名区域）。
下面是没有集群支持的架构。
- nGrinder使用嵌入式SVN服务器（SVNKit DAV）来管理脚本文件。SVN存储库存储在${NGRINDER_HOME}目录中。
- nGrinder使用EhCache提高DB和SVN存储库的数据检索性能。
- nGrinder使用Spring Security来保护系统，并使用Atlassian插件框架来实现可扩展性。
如果通过配置system.conf启用集群模式，将nGrinder安装到多台机器上，系统架构将变更如下：
- 集群中的所有控制器共享同一个DB和文件系统。所有nGrinder控制器都应该指向由NFS共享的${NGRINDER_HOME}文件夹。
- 每个控制器都可以有自己的特殊属性和日志输出文件夹。这些信息将保存在每个控制器的${NGRINDER_EX_HOME}中。
- 所有控制器相互复制EhCache，使某些数据在集群中的所有控制器中可见。
每个控制器都可以为nGrinder Web内容提供服务，但是根据不同的命名区域处理不同的测试集。默认情况下，我们不提供任何会话集群。因此，您可能会遇到登录问题，因为存储在控制器中的会话不会复制到其他控制器。您可能需要通过引用Tomcat会话集群指南来配置它，或者在L4上使用粘性会话。如果您不是这方面的专家，只需让用户只连接一个控制器即可。