测试方式：
3台计算机并发模拟客户登陆及聊天。登陆包括查询与下载好友列表、好友资料、群组列表、群组资料；聊天测试方式为，每个模拟客户端每1秒向好友列表中的一个好友发送一条文本消息。所有好友消息均为服务器转发，因为如果使用P2P方式的话，一旦P2P通道建立，数据便不再经过服务器，对IM服务器的压力不产生影响，因此，便没有测试P2P方式下的压力数据，而选择测试服务器转发方式下的压力数据。

最终的测试结果为：
服务器转发模式下，大约能同时支持3000人登陆，4865人同时聊天（服务器崩溃前最近一次读数）。
光登陆就超过2000，令人非常满意，而且4865人同时聊天，这还是在未进一步优化的情况下获得的数据。接近5000的数据，令人很是高兴。

最后，IM服务器的架构简述：
采用4IOCP。其中一个TCP IOCP用作管理员客户端连接，以及将来的服务器聚合扩展；一个TCP IOCP用于用户客户端登陆登出，以及数据补包；一个UDP IOCP用于心跳、P2P打洞处理、中转聊天的文字消息（包含系统表情）；一个UDP IOCP用于中转聊天的非文本数据（比如图像）。4个IOCP间的桥接及系统日志、管理员日志、用户日志、插件日志均采用队列处理。系统所有内存使用均有专门的内存管理器负责管理。至于UDP为什么也要采用IOCP，原因则是，虽然普通的UDP已经很快了，但是，每次发送，接收仍均需要阻塞等待。虽然每次阻塞的时间很短，但积少成多，在大量连接的情况下，仍然会比较可观。而采用IOCP，则就是为了经量减小每次阻塞的时间。
最后，关于系统资源占用：
CPU：4%-9%。即使达到4865用户同时在线聊天，CUP占用率也一直处于4%-9%
内存：IM服务器刚刚启动时，占用内存7M多，当4865用户同时采用服务器中转方式在线聊天时，达到190M。

虽然这些工具给我们测试服务器承受能力带来方便，但是它们的危害却更是惊人，甚至于利用随便一种比较全面的测试工具就可以对一台小型的 Web服务器发动灾难性的拒绝式攻击。下面我就带大家利用微软的Web Application Stress进行一次Web压力测试，其目的是为了让大家看到它的巨大危害。

一、工具简单介绍

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的客户端计算机仿真大量用户上线对网站服务所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。就是因为这些特性，才使它具备了D.O.S轰炸的功能。

小提示：D.O.S（拒绝服务攻击）通过使你的服务计算机崩溃或把它压跨来阻止你提供服务。简单来说，就是让你的计算机提供可能多的服务从而使你的计算机陷入崩溃的边缘或崩溃。

二、工具简单设置

打开Web Application Stress Tool，很简洁的一个页面（如图1），上面是工具栏，左下方是功能选项，右下方是详细设置选项。在对目标Web服务器进行压力测试之前，先对它进行一些必要的设置。

图1

1. 在“settings”的功能设置中（如图2），一个是Stress level (threads)这里是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，更加形象的就是说设置多少轰炸的线程数。一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么设置的越高，轰炸的效果越好。

图2

2.在“Test Run Time”中来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，你根据实际情况来设置吧！

3.其余的选项不太重要，这里就不再浪费笔墨，朋友们可以自己尝试一下设置。

三、压力测试

工具介绍完了，下面来准备条件：这里与一个朋友商量好进行测试，他是单机上网，机器配置是CPU:Athlon XP2500+、内存512MB、硬盘80GB等，机器配置还不错。他在机器上安装了IIS，架设了一台对外的Web服务器，Web服务中的程序是动网 7.0。我就利用压力测试工具对这台服务器进行测试。

步骤1：在工具中点右键，选择Add命令，增加了一个新的测试项目：New script，对它进行设置，在主选项中的server中填写要测试的服务器的IP地址。在下方选择测试的Web连接方式，这里的方式Verb选择 get，path选择要测试的Web页面路径，这里填写/Index.asp,即动网的首页文件（如图3）。

图3

步骤2：在“Settings”的功能设置中将Stress level (threads)线程数设置为1000。完毕后，点工具中的灰色三角按钮即可进行测试（如图4）。测试完毕，等待朋友把任务管理器以及连接查看的截图发过来！

图4

攻击开始后，朋友从任务管理器中可以看到CPU使用率已经达到100%，损耗率达到最大（如图5）。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服务器上的80端口进行了非常多的连接（如图6）。而且它的Web网站已经打不开了，提示过多用户连接，达到了跟 D.O.S攻击一样的目的。

图5

图6

试想，如果利用多台肉鸡对一台服务器进行Web压力测试，那么对这台服务器来说将是灭顶之灾，所以朋友们在使用它之前一定要慎重考虑。

一、 使用VUGen录制脚本

1、根据应用程序架构选择相应的协议。一般象B/S的程序用单一的http协议就可以了。

2、开始录制。根据所选协议的不同，出现的对话框不不同的。选择http协议的话需要录入url地址，在这步录入需要测试的地址如https://www.alipay3.net。

3、录制脚本：在一个脚本中，默认有三个动作：vuser_init Action vuser_end。通常把初始化操作放到vuser_init中，具体需要测试的操作放在Action中，vuser_end动作目前来说没有什么用处。在创建交易脚本中，需要测试的操作包括创建支付宝交易、买家付款、卖家发货、买家确认收货。每一个操作都必须首先登陆才能进行。

4、添加事务：为了使录制的脚本更易读，录制过程中要为每一个独立的操作添加事务。比如说登陆、买家付款都放在一个单独的事务中。特别注意，因为本次测试目标是每秒内总的交易数，所以需要分别给每一个测试脚本的Action操作都加上一个统一的事务，名称都叫做“Action”，以便衡量是否可以达到目标。

5、添加验证点：脚本录制好后，在需要的地方加上验证点，来检测脚本是否执行成功。以登陆操作来说，在提交登陆的脚本后面，右击鼠标，选择Insert—NewStep，在出现的对话框中选择Web Checks—Text Check，进行文字验证，查找退出这两个字是否出现。如果出现就说明登陆成功了。

6、根据需要对变量参数化：在登陆操作中需要参数化的值包括：URL，登陆帐号、登陆密码。点击工具栏的Param List按钮可以创建参数。当新建一个参数后，LR会在当前脚本的目录下自动创建一个文件存放参数的值。我们不要这个默认的文件名，把所有参数的文件名都修改为“D:\LrData\Email.dat”[文件路径及名称都是可以手工修改的]，这样可以在多个脚本中共享相同的变量。

a)        url、登陆帐号、登陆密码：这几个参数都是手工在LR中输入，然后保存到文件中。

b)        交易号：在查询交易明细脚本中，会随机的选取100个交易查看其明细。这种情况下，交易号直接从数据库中取得比较方便。但是必须在本地安装oracle客户端。如果没有装oralce客户端，可以首先登陆到PL/SQL中，查询100个交易号，选中把查询结果，选择导出到CSV文件中。如下图：

导出后，在LR中打开Param List，选中交易号这个参数，点击Edit With NotePad按钮，把csv文件的内容拷贝到这个里面即可。注意拷贝前需要用支持列编辑的文本工具打开csv文件，去掉前后的引号。保存文件成功后，在LR中就可以看到导出的交易号了。

7、在Vuser中运行脚本，确认脚本可以正常运行。

二、            使用Controller设置场景进行测试

1、创建场景：由于我们这次的测试目标是以每秒N个交易，所以选择基于目标的场景。创建场景的同时，加入需要测试的脚本。

2、定义测试目标：

场景创建成功后，单击Edit Scenario Goals定义测试目标。

在这个对话框中新建一个测试目标，类型为：Transactions per Second，事务名称为我们统一定义的“Action”，事务数量根据需要设置。Vuser的数量设置从20到500。

3、设置运行时间：

也是在Edit Scenario Goals中，可以设置达到目标后再运行多少时间。

4、Run-Time Setting：(特别注意)

在VuGen中也有Run-Time Setting，但是在那里设置好的参数不会被带到Controller中，需要重新设置。对每一个脚本都需要设置。

a)        Think Time：这个选为Ignore think time，否则结果中的事务响应时间很大，包含了这个思考时间。

b)        打开验证点检查功能：在Preferences选项中，给Enable Image and text check打勾，否则脚本执行时不会去检查验证点的。

c)        设置Action的迭代次数：在Run Logic中，单独设置脚本中每个动作的执行次数。例如在查询交易明细脚本中，需要模拟一次登陆，查询10次明细的情况，就需要设置Action动作迭代10次。

5、添加需要监控的性能参数

这次我们测试的服务器是Linux，需要得到在各种压力下服务器的负载情况。Linux的性能参数在场景中没有默认被监控，所以需要手动添加。要监控Linux的资源，需要在服务器上运行一个叫做rstatd的进程，这个进程可以从网上下载。在服务器上启动这个进程后，

在测试场景中，手工将Available Graphs的UNIX Resources拖动到右边的视图中，然后右击，选择Add Measurements，添加需要监视的服务器。

图中，上面一个Add添加需要监视的服务器，下面的Add是用来添加需要监视的参数，包括Average Load等等。

6、运行场景，保存执行结果

运行时，需要选择运行结果保存的路径及文件。这些结果文件可以在Analysis中查看。

三、            查看运行结果

第二步场景运行结束后，通过菜单Results—Analysis Results打开运行结果。

在Analysis中，默认显示以下类型的结果分析图。

需要手工把Unix资源的图打开，单击上图中的New Graph，出现下面的对话框。

选择System Resources下的UNIX Resources，单击Open Graph，就可以看到在场景中所监视的各个性能指标的曲线图了。

点击保存可以把结果保存为*.lrr的文件，下次可以直接通过Analysis打开。

四、            比较2次或者多次场景运行的结果

测试中，为了提高系统的性能，会修改代码或者更改架构，这时候我们需要对修改前后的场景运行结果进行比较，通过一些性能指标的曲线图比较直观的了解系统的变化。

在Analysis中，通过菜单File—Cross With Result可以合并结果进行比较。

通过Add按钮可以添加多个*.lrr文件进行结果的比较，点OK后会出现各个结果的比较图。