服务器性能测试工具的架构
用户行为生成部分
我为什么说的这么朦胧，对于熟悉loadrunner的朋友，我说成虚拟用户脚本生成器，你更容易理解，这个脚本，我们可以录制，也可以手工编写。你不要以为这是生成用户行为的唯一方式。因为在JMeter成中是添加各种组件，通过对组件的配置来完成用户行为的，当然也可以通过录制。而在相对简陋的性能测试工具curl_loader（linux环境下的运行的），他是通过编写配置文件的形式来描述用户形为的。
我前面也有提了，虽然性能测试工具由不同的形式来描述，但他们的原理是一样的，都是通过Proxy方式来实现，具体来说，Proxy作为客户端和服务器之间的中间人，接收客户端的数据包。
压力产生器
压力产生器用于根据脚本内容产生实际的负载，在性能测试工具中，压力产生器扮演着“产生负载”的角色。也就根用户的设置，进行自我复制来生成多个客户端向服务器发送请求。对于工具来说，每复制出来的一份就是一个进程或线程，进程和线程的运行是要占用系统资源的。所以，对一台压力测试机来说能运行的虚拟用户数也是有限的。根基测试机的配置而定。那么这个时候就要通过多台测试机合作，来模拟更多的虚拟用户向服务器发请求。
那么，对于性能测试来说，很重要的一点就是产生“并发”的请求，不然就不会对服务器产生压力。那多台机子如何产生“步调一致”的虚拟用户呢？使用“用户代理”
用户代理
用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或线程协作，接收调度系统的命令，调度产生负载压力的进程或线程，从这个意义上看，用户代理也是压力产生器的一部分。
调度能力
我们在做复杂的性能测试时，常常会设计各种场景，不同的虚拟用户数，不同事务的用户比例，运行时间，设置同步点等，这个时候也需要我们的测试工具有压力调度能力。从而才能更真实的模拟我们所设计的运行场景。
监控系统
监控系统是性能测试工具直接与用户进行交互的主要部分，监控系统，主要用户在压力测试过程中对各种软硬件进行监控，如对数据库、应用服务器，服务器的主要性能表现情况进行监控。用于判断系统当前处于什么状态。
当然，监控系统不是性能工具必须的部分，可以通过软硬件系统自身的监控工具或者第三方监控工具进行监控。但是否有强大的性能计数器监控系统是衡量性能测试工具是否强大的指标之一。
压力结果分析
压力结果分析工具可以用来辅助进行测试结果的分析，性能测试工具一般都能将监控系统获取的性能技术数器值生成曲线图，折线图等各种图表。通过展现性能测试过程中的各种参数指标，来供测试人员进行分析。
但这里需要强调的是，压力结果分析工具本身不能代替分析者进行性能结果分析，而只是提供多种不同的数据揭示和呈现方法而已。对于这些数据进行分析必然要依靠测试工程师对系统性能分析的知识和经验。
对上面介绍的性能测试工具架构的组成部分，不是第一个性能测试工具都具备，而所具备的强大程度也不相同。比如，有些性能测试工具不具备用户代理能，有些监控系统能监控的资源很有限或简陋，有些结果分析数据的呈现不够详尽等。
相关链接：
