【适用范围】
EOS运行环境
HP小型机 4G内存，4个双核CPU，DB Server 和Web Server 都是装在这台机器上。LoadRunner 在另一台PC 机器上，EOS安装是5.3 版本。
【问题描述和定位】
测试场景：用户登录
LoadRunner 并发测试结果数据
10用户并发 平均事务响应时间为 0.8 秒
当我们看到这个数据，我们大为吃惊，这么好的机器怎么跑出来这样的数据。于是检查各方面的配置情况，基本上都没有大问题，我们监控系统资源，发现CPU 资源始终为 10%左右，老是上不去，但是Orcale 占用资源比较多，开始我们怀疑是 DB 和 web服务器在同一台机器上的原因，但根据ＣＰＵ资源的利用率情况来看，不是关键问题的所在。后来我们继续跟踪，发现操作系统是redhat 64 位的，Oracle １０ｇ也是６４位ＪＶＭ ，用ＳＳＨ连上去，用ｖｉ操作文件，发现响应时间特别长，还以为是６４位操作系统这个时髦玩意哪里不兼容。周折一段时间，确认是客户端和服务器端的网路问题造成的。
解决网络问题后测试数据
10用户并发 平均事务响应时间为 0.06 秒
【解决方案和步骤】
下面是定位方法和步骤主要介绍用LoadRunner 来分析网络问题
问题定位步骤：
1、 首先了解服务器的配置
略
2、 检查ＥＯＳ相关的配置文件
这个步骤，像JVM 内存、线程数、EOS性能优化文档上有详细说明，这里就不再复述。
3、 利用 LoadRunner 分析测试结果
首先分析：Throughput (吞吐量)
在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。拿这个值和网络带宽比较，可以确定当前网络是否是系统性能瓶颈，如果随压力的增大，而Throughput值程水平线，那么说明网络带宽不能满足目前系统流量。
分析：Average Transaction Response Time(平均响应时间)
在LoadRunner 中可以分解每个请求，能够获取每一个页面上的元素所消耗的时间。
下面简单的说一下浏览器发送一个请求到最后显示的全过程：
1. 浏览器向Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS
名字解析成IP 地址。解析的过程的时间就是“DNS Resolution”。这个度量时间可以
确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况
比较好，该值会比较小。
2. 解析出Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和Web
Server 之间需要建立一个初始化连接，建立该连接的过程就是“Connection”。这个
度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请
求。如果正常，该值会比较小。
3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器
成功接受到第一字节的时间就是“First Buffer”。这个度量时间不仅可以表示Web
Server 的延迟时间，还可以表示出网络的反应时间。
4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时
间就是“Receive”。这个度量时间可以判断网络的质量（可以用size/time 比来计算
接受速率）
【备注】
特别要注意：我们通常用Receive 指标来判断网路的质量，当你页面上的元素如图片，css，js 等文件非常小(小于2KB)，这时你会发现Receive 的时间几乎为０，所以它将误导你的判断，以为网络没有问题。 | 
