如果是线程安全的协议，在一个组（进程）里并发多个vusers，可以不用开那么进程。这可以减少系统的开销。
　　如果不是线程安全的协议，我们需要开多个进程来处理Ｖusers。这样势必增加系统的开销。
　　其实对现在的硬件来说，基本上客户端成为瓶颈的机会不是很大。（除非这公司太穷了）
^_^

　　这里我做了个实验，画了一张表，来形象的说明一下组/vusers/线程／进程的关系。
注：这里，我假定的是１０vsuers：
 

设置vusers按进程还是线程运行	Vusers(个／组)	组（个）	mmdrv.exe中的线程数（个／组）	Mmdrv.exe进程（个）	平均每个进程占的内存（k）	Mmdrv.exe占有内存总数（k）
线程	１０	１	１２	１	７，５００	７,５００
线程	１	１０	３	１０	５，１５０	５１，５００
进程	１０	１	１	１０	４，６７６	４６，７６０
进程	１	１０	１	１０	５，１５０	５１，５００

　　我这里脚本都是一样的。
　　大家如果自己做实验，内存可能会不一样。
　　在表里，我们可以很清楚的看到，进程多的时候，占用内存肯定是多的。
　　如果在同一组里开多个线程，占用内存就少得多。
　　我们还要注意一个细节就是在用线程来运行vusers的时候，每个进程中会多出几个线程来。
　　这多出来的很个进程在做什么，我没有查它的ＡＰＩ，我想可能是维护进程之间的运行。
 
　　很显然的，还有个问题，就是哪个压力更大。
　　这个问题也有些人在问，我想这个应该是很明显的吧。
　　其实对服务器来说，只要是１０个用户都在正常工作，而速度不会受到本地硬件的影响。
　　对服务器的压力是一样的。
　　这么来思考：
　　假设来说。
　　我们是从客户端来发数据库的，１０个用户，如果一秒钟发２０个数据包。
　　那对服务器来说，收到的数据包都是一样多的。所以压力也会是一样的。
　那会不会存在在同一个进程里开１０个线程速度更慢呢。
　　这个，我以为不会的。
　　所以我认为压力是一样的。

最近使用LoadRunner进行Winsock协议的性能测试时，测试的WebServer是JBoss，经常出现10053错误，现象如下：当我用lrs_create_socket创建连接之后，当这个socket 连接的请求次数达到100次后，这个连接就不可用了，必须close后再重新create。LoadRunner提示错误：Error : socket0 - Software caused connection abort. Error code : 10053.

　　经过多次探索，终于发现该错误是由于Apach HTTPServer中HTTP 1.1 版本KeepAlive参数的配置原因导致的。从我对多个不同WebServer的测试结果来看，在一个Socket连接进行100个请求时出错的有JBoss和Tomcat，其它 Web服务器如IIS、WebLogic均没有该问题。
下面介绍几个相关的参数：KeepAlive 、KeepAliveTimeout、MaxKeepAliveRequests。

KeepAlive Directive
Descrīption: Enables HTTP persistent connections
Syntax: KeepAlive On|Off
Default: KeepAlive On
Context: server config, virtual host
Status: Core
Module: core

　　在HTTP 1.0中，一次连接只能作传输一次HTTP请求，而KeepAlive参数用于支持HTTP 1.1版本的一次连接、多次传输功能，这样就可以在一次连接中传递多个HTTP请求。虽然只有较新的浏览器才支持这个功能，但还是打开使用这个选项。

The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.

For HTTP/1.0 clients, Keep-Alive connections will only be used if they are specifically requested by a client. In addition, a Keep-Alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI pages, and server-generated directory listings will generally not use Keep-Alive connections to HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.

－－－－－－－－－－－－－－－－－－－－－－

KeepAliveTimeout Directive
Descrīption: Amount of time the server will wait for subsequent requests on a persistent connection
Syntax: KeepAliveTimeout seconds
U |SySs%y2a1691Default: KeepAliveTimeout 15
Context: server config, virtual host
Status: Core
Module: core

　　KeepAliveTimeout测试一次连接中的多次请求传输之间的时间，如果服务器  已经完成了一次请求，但一直没有接收到客户程序的下一次请求，在间隔超过了  这个参数设置的值之后，服务器就断开连接。

The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

－－－－－－－－－－－－－－－－－－－－－－

MaxKeepAliveRequests Directive
691Descrīption: Number of requests allowed on a persistent connection
Syntax: MaxKeepAliveRequests number
Default: MaxKeepAliveRequests 100
Context: server config, virtual host
Status: Core
Module: core

　　MaxKeepAliveRequests为一次连接可以进行的HTTP请求的最大请求次数。将其值设为0将支持在一次连接内进行无限次的传输请求。事实上没有客户程序在一次连接中请求太多的页面，通常达不到这个上限就完成连接了。

　　The MaxKeepAliveRequests directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.

For example:MaxKeepAliveRequests 500

　　最后，虽然这个问题是由于HTTPServer的参数配置引起的，但只有LoadRunner才会出现这个问题，如果用Rational Robot实现同样的功能则没有该问题，由此估计和测试工具对Socket连接的实现策略也有一定的关系。

很多时候一提到不是基于浏览器的应用，很多人就会想到用WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。

        从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。

        因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。

        很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。

        所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。

        附件是我们自己开发的Controller，我们自己用面向对象实现了并发测试架构（目前支持并发、迭代、thinktime、参数文件、启动时间间隔，集合点功能正在开发中）。借助我们自己开发的Agent，能很好的测试我们的C/S架构的程序。
        这个工具和LoadRunner配合起来，可以完成大多数性能测试。
        这个工具主要为我们测试视频播放效果而开发，呵呵。这是LoadRunner不太擅长的。

 

因为在客户端发request的时候，是不会管服务器的状态的。

        下面打个比方，具体数据，不可做任何参考，只是我临时编的。
        比如：服务器可以同时每秒处理100次点击，这时，需要调用服务器的一些资源来处理，像：JDBC连接、内存、开socket等等，其他的用户呢？应该都在排队状态，而服务器处理完了前面的用户后，需要一些时间来释放这些被占用的资源，假设为1秒，如果LR采样的时长为2秒，那么服务器处理的用户应该为50次点击／每秒，按这种理想状态，点击率的图应该是比较平稳的。
        但是，系统受的压力会随着点击的增加而增加，系统性能也就慢慢的下降，例如释放资源的速度开始变慢、换页开始频繁，那么，后面的点击造成的请求，很有可能需要等待的时间随机变长。但是采样的频率是不变的，所以后面的采样值应该慢慢的变小。
       也就是像有些图中所显示的那样：随着场景时间的持续，点击率，吞吐量等图的曲线慢慢的下降。

        而出现超时的现象也很好解释了，无非是有些请求，等待的时间太长了。

        有些图呢是比较稳定的，曲线平稳，这时可以认为，系统可以承受当前用户量的压力。

        而有些场景会出很多超时的错，这就有可能是系统承受不了这种的压力，或者配置上有些问题。

        需要综合分析了。

测试环境描述：

        客户端 5台 Windows2000机器。服务器端  20台机器 一台F5（负载均衡设备，提供一个唯一的IP供客户端访问）

        客户端绑定Host后，使用域名http://www.****.com来访问。

        为了说明问题，简化的脚本说明如下。
        协议:http/html vuser_init:登陆；Action:查询某笔交易，查询成功的前提是用户必须登陆；vuser_end:退出  运行时设置参数Browser Emulation采用的是默认值。场景设置的是Goal-Oriented。
      在运行时发现，登陆都能成功，但是在执行Action时，部分成功，部分失败。为了查明失败的原因，在Vuser Generator中调试脚本，设置Action运行100次。每次运行时，总有一部分成功，一部分失败，而且是不规律的。这时候联想到服务器端有好多台机器，是不是因为把查询交易的请求分发到不同服务器导致查询时因为没有登陆而失败呢。

        那么有什么办法让每一个Vuser访问固定的一台机器呢？这也符合实际的业务情况，当一个用户登陆后，他所进行的一系列动作都是在同一台服务器上完成的，否则会不定时的让用户重新登陆。此时查看Browser Emulation，发现有一个设置“Simulate a new user on each iteration”。根据LR给出的解释是：在每一次迭代完成后，VuGen会把所有的http状态设置为vuser_init完成后的状态，然后以新的用户进行下一次迭代。现实的情况是，如果每次Action迭代时，F5会根据当前服务器的使用情况把请求分发到空闲的机器上。这时就出现了上面所说的问题。把此选项去掉后测试成功。

    昨天在研究脚本的时候偶然遇到一个问题，今天正好有了点时间，就拿来再研究一下。
　　问题是这样的：我想用strcpy函数把一个字符串赋给一个变量，再将这字符串做一个参数化，然后我想看看参数化是否成功，于是我用了lr_message函数把它打印出来。脚本代码很简单，如下所示：
  Action()

{
    char a[10];

    strcpy(a,"{a}");
    lr_message(a);
    return 0;

}
　　其中，{a}我已经做了参数化，参数值为11。
　　运行这个脚本后，发现运行日志里打印出来的a值显示为{a}。

　　在尝试了N遍以后，我把lr_message(a);这句代码改成lr_message(lr_eval_string(a));后问题解决，运行日志里打印出了我所期望的值11。51Testing软件测试网 L KG3[$~c"f
　　问题虽然解决了，但我还是很纳闷，为什么在用lr_message的时候不能直接引用参数，而我记得之前在web_url、web_submit_data等函数里都是可以直接引用参数化的值，而从来没有出现过问题。也许是在LoadRunner里，这几个函数对参数值的引用方式不同吧，不知道我这样想是否正确，希望大家批评指正！
 

　　昨天和Zee讨论了一个下午，结论还是没有明确。今天上午继续试验，试验结果表明Zee说的是正确的，不能直接将C语言里的变量直接当作LR变量使用，而需要做一些转换。事实上，执行strcpy(a,"{a}");后，并没有真正将参数值传给a。需要这样写：strcpy(a, lr_eval_string("{a}"));这样就没问题了。

　　不过，问题还没有结束，在tuxedo协议中，用 lrt_strcpy函数则没有这个问题存在，例如：lrt_strcpy(sendBuf1, sendBuf);则可以成功地将sendBuf中的参数值赋值给sendBuf1。目前怀疑是该函数在内部已经进行过转换，但并不肯定，尚待证实。 

　　再次针对以上问题进行试验，我在lrt_strcpy(sendBuf1, sendBuf);语句的前后各加了一句调试信息：lr_output_message("sendBuf:%s",sendBuf);

和lr_output_message("sendBuf1:%s",sendBuf1);

 　　打印出来的结果截然不同，前者的输出显示没有传入参数值，而后者则成功传入参数。这表明确实是lrt_strcpy这个函数在搞鬼。

 我们在使用LR进行性能测试的时候，经常有需要监控OS的资源使用情况的需求。对于 Windows系统，这个工作进行起来很方便，直接在LR的资源监控窗口中添加需要被监控的机器名或IP即可，但对于Linux/Unix系统，则要稍微复杂一些，我在这里简单介绍一下如何在LR中监控Linux/Unix系统的资源使用情况：

　　Linux

　　对于Linux系统，要想通过LR监控Linux/Unix系统的资源使用情况，需要运行rstatd服务。如果OS没有安装rstatd(可以查找一下系统中是否存在rpc.rstatd这个文件，如果没有，则说明系统没有安装 rstatd)，则需要进行安装。rstatd安装步骤如下：

　　获得rstatd的安装介质(rstatd.tar.gz)。rstatd可以从 redhat的安装CD中获得，或者从网站上下载(给出一个下载地址，sourceforge的： //heanet.dl.sourceforge.net/sourceforge/rstatd)。

　　将rstatd.tar.gz拷贝到Linux系统中，解压，赋予可执行权限，进入rpc.rstatd目录，依次执行如下命令：

　　#./configure

　　#make

　　#make install

　　结束后，运行./rpc.rstatd命令，启动服务。这个时候，你就可以在LR中监控Linux资源了。

　　Unix

　　对于Unix系统，比如Solaris，AIX或者HP UX等，它们的配置过程比较简单——在inetd.conf(在/etc目录下)文件中去掉rstatd前面的注释，然后启动rstatd服务即可。