如何测试web服务器的网速

电脑进入运行程序，输入CMD，然后键入ping+空格+你的IP地址（+号无需输入），按回车键就可以了。

如果是联通宽带用户，可登陆网上营业厅www.10010.com 后，首页点击“我的联通”-“便民服务”-“宽带测速”，即可根据页面提示信息进行测速。也可以使用宽带号码登录联通手机营业厅客户端——查询——宽带业务查询——立即测试（“宽带测速”业务不支持免流）。

温馨提示：以上路径以网上营业厅实际显示信息为准。

1.具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2.查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈 �8�1 网络瓶颈（对局域网，可以不考虑）�8�1 服务器操作系统瓶颈（参数配置）�8�1 中间件瓶颈（参数配置，数据库，web服务器等）�8�1 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

分析的信息来源：

1 根据场景运行过程中的错误提示信息

2 根据测试结果收集到的监控指标数据

颜色比例度量图最小值平均值图最大值图中间值图SD

1Throughput1257502.7951375591.3721525865.0471372743.69149130.473

同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。

6．下载组件大小

每个页面的组件大小，且包括组件的标头的大小！

页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！

7．Apache资源

显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。

颜色比例度量最小值平均值最大值SD

100Apache CPU 使用情况(Apache):172.17.7.2100.7770.8520.930.043

0.01已发送 KB/秒(Apache):172.17.7.21061430.3712689.333327.924

0.1点击次数/秒(Apache):172.17.7.2100.333114.352533.66740.201

三．服务器资源监控指标：

（目前通过top监察）

内存：

Linux资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate)

进程进入不活动状态

交换区所有磁盘的活动次数可高

可高的全局系统CPU利用率

内存不够出错(out of memory errors)

处理器：

Linux资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95％），表明瓶颈是CPU。

实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86％以上！

说明，目前系统用应用的cpu也是测试的瓶颈！

CPU资源成为系统性能的瓶颈的征兆:

很慢的响应时间(slow response time)

CPU空闲时间为零(zero percent idle CPU)

过高的用户占用CPU时间(high percent user CPU)

过高的系统占用CPU时间(high percent system CPU)

长时间的有很长的运行进程队列(large run queue size sustained over time)

四．数据库服务器：

数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！

五．结论

以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。

根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！

Tomcat既支持阻塞式IO，也支持非阻塞式IO。

如果要使用NIO，需要修改server.xml的配置。

<Connector executor="tomcatThreadPool" port="8080" [color=red]protocol="org.apache.coyote.http11.Http11NioProtocol"[/color] connectionTimeout="20000"

redirectPort="8443" URIEncoding="UTF-8"/>

web服务器一般有两种处理http请求的机制，阻塞和非阻塞，阻塞式因为每一个连接都产生一个线程，当线程数达到一定数量的时候，CPU用于线程切换的时间会变多，整体的性能会下降，所以线程池的数量要控制在一定的数量内，这是就需要引入非阻塞的机制，就是把连接先缓冲在一个队列中，然后再分给后台的线程池中的空闲线程慢慢处理。

Comet属于长连接，所以对于web服务器的吞吐量要求要更高，也就是要具备处理大量http请求的能力，所以必须使用Http11NioProtocal来提高吞吐量。

至于把连接缓存在队列中，依然排队等待的问题，和阻塞式处理方式比，至少客户端不会收到500 connection refused，只是感觉响应慢一些，还有因为comet属于消息推送，一般客户端的http请求是异步的，比如通过ajax在后台发起http请求，所以对于这种情况，连接缓存在等待队列中也没有关系，因为是异步的，而且用户也看不到，所以对用户的使用也没有影响。

下面看一下这两种方式的区别：

1.Http11Protocal

使用阻塞IO,服务器端使用Socket类和ServerSocket类负责请求的接入

一个请求接入线程，专门负责请求的接入accept，接入后把socket扔给后面的线程池，线程池中有具体的处理线程，负责后续的处理，一个线程对应一个请求，直到请求处理完毕并返回response，这个线程数就是web服务器能承载的最大线程数，如果线程池中没有空闲线程，那么下一个请求就无法接入，如果ServerSocket的等待队列也满了的话，客户端就会收到500 connection refused。

2.Http11NioProtocal

使用非阻塞IO，服务器端使用SocketChannel类和ServerSocketChannel类负责请求的接入

这种方式也有一个请求接入线程，专门负责请求的接入accept，但是接入后不是直接扔给后面的处理线程池，而是又多了一个或两个中间线程，这个中间线程里面有一个队列，接入后直接把SocketChannel以及对应的Selector监听信息包装成一个事件对象扔到中间线程的队列中（如果有两个中间线程，那么平均使用这两个线程，这次是线程1，下次是线程2，在下次是线程1，以此类推，所以每个中间线程会处理多个连接），这个队列可以容纳足够多的事件对象，Selector相当于对socket状态进行监视的监听器。这个中间线程不断地对这个事件队列进行循环处理，当Selector中有需要处理的事件时（比如socket read就绪，socket write就绪），再把socket转给后面的处理线程池进行后续的处理。

前面提到的中间线程可以有一个或者两个，每个里面都有一个队列，所以可以容纳足够多的socket连接。这样即使后面的线程池中没有空闲线程，一样可以对请求进行接入，然后缓存在中间线程的队列中。这样就加大了web服务器的吞吐量。comet长连接很多时也可以应付得了。

这种方式不单单是对连接进行缓存，前面提到了中间线程对Selector中的事件进行监视，直到有事件到达时才把socket转给后台线程池进行处理，这样就减少了线程池中的处理线程的等待时间，此外，对每个SocketChannel都分配了readbuffer和writebuffer,这样可以减少实际的socket流的读写次数，以减少IO等待。

---