3.1.JVM参数的配置
Tomcat默认可以使用的内存为128MB，在此次的测试中，这点内存是不够的，当内存不够用时，报tomcat内存益处错误。解决方法主要是加大TOMCAT可利用内存，因此根据应用的需求，有必要调整JVM使用内存的大小。catalina.bat文件的内容，即在里面增加一行代码：set JAVA_OPTS=-Xms512m –Xmx1024m。JVM的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长，一般建议JVM的最大值设置为可用内存的最大值的80%。

3.2.连接数参数的配置

在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：
maxThreads： Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值150。

acceptCount： 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值100。
minSpareThreads： Tomcat初始化时创建的线程数。默认值25。
maxSpareThreads： 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值75。
enableLookups： 是否反查域名，默认值为true。为了提高处理能力，应设置为false

connnectionTimeout： 网络连接超时，默认值60000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为20000毫秒。
  其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

3．3.应用系统连接池的配置参数
初始化后连接个数
<initialConnections>5</initialConnections>
最小连接个数
<minimumSize>5</minimumSize>
最大连接个数
<maximumSize>200</maximumSize>
达到最大连接个数后是否可以再创建新的连接
<maximumSoft>true</maximumSoft>
XX秒后destory连接
<connectionTimeout>600</connectionTimeout>
在返回连接池前用户可以保持XX秒
<userTimeout>12</userTimeout>

二 LoadRunner方面：

1.脚本录制

在测试过程中，出现脚本录制不到的情况，可能影响的原因：①网络不通。②杀毒软件的原因，防火墙阻止了LR脚本录制的进行。用HTML录制的脚本回放时报错，选择URL模式录制后能够通过。原因是:基于浏览器的应用中包含了向服务器进行通信的JavaScript代码，应当使用“URL-based script”模式进行录制。

2.迭代与Pacing的设置意义
迭代是对Action部分的循环操作，通过设置迭代可以让指定的部分循环运行，这在测试系统的稳定性的时候能够用到。Pacing表示的是对每次迭代的时间间隔，设置这个时间可以降低服务器压力，更加真实的模拟现实情景。

3.参数化，取值方式的选择
“Select next row”选择数据输入更新方法，以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是：连续的、随机的、唯一的、或者与其它参数表的相同行。
① 顺序（Sequential）：顺序地给虚拟用户分配参数值。
②随机（Random）：从数据表中取随机数
③ 唯一（Unique）：分配唯一的值给虚拟用户。

“Updta value on”选择数据的更新方式。
①Each iteration：每次循环取新值，每一次循环中都取相同的值。
②Each occurrence：只要发现该参数就要重新取值。
③Once：在所有的循环中都使用同一个值。

4.集合点策略与思考时间的运用
通过集合点与思考时间的综合运用，实现了在线数的测试。模拟100个虚拟用户同时在线：集合点策略中设置当20个虚拟用户到达集合点时就释放进行并发操作，在退出之前加入思考时间，当20个虚拟用户并发操作后没有立即退出而是在等待其他80个虚拟用户。通过设置合理的思考时间，能够让100个虚拟用户同时在线。

5.设置不同角色的用户组，真实模拟现实场景
在现实场景中，会有不同角色的用户登录应用系统，为了真实模拟环境，应该设置不同角色的用户组进行测试。

6. 加压方式，持续时间（优先迭代的选择），减压方式的选择与意义
Ramp Up：同时加载所有虚拟用户；每隔一段时间加载一定数目的虚拟用户。

Duration：按照指定的迭代次数运行；按照指定时间运行；一直运行，直到人工进行干预。

Ramp Down：立刻同时停止；每隔一段时间停止一定数目的虚拟用户。

意义：通过合适的选择，能够真实模拟现实环境，达到测试目标。

例如，测试每5秒加载10个虚拟用户，持续运行1小时，那么在这里进行相应的选择就可以按照描述进行测试。

7.监视Oracle数据库服务器的方式与需要监视的数据
方式：

①安装Oracle客户端

②添加监听程序

③获取system帐号密码

④在LR中以system身份连接，添加计数器。

8.监视Windows操作系统的方式与需要监视的数据
方式：

①在图树中单击 Windows 资源图，并将该图拖进“运行”视图的右窗格中。

②右键单击该图并选择“添加度量”，或选择“监视器” > “添加联机度量”。

③在“Windows 资源”对话框的“监视的服务器计算机”部分，单击“添加”以输入要监视计算机的服务器名或 IP 地址。选择计算机运行的平台，单击“确定”。

④在“Windows 资源”对话框的“资源度量”部分中，选择要监视的度量。

需要监视的主要数据：

内存相关：Available Mbytes（可用物理内存数）；Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径；如果队列长度增加的同时页面读取速率并未降低，则内存不足。

处理器相关：%Processor Time:如果该值持续超过95%，表明瓶颈是CPU；Queue Length队列长度持续大于 4 则表示可能出现处理器拥塞；%User Time:表示耗费CPU的数据库操作，如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

带宽相关：Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，用该计数器的值和目前网络的带宽相除，应大于50%。

进程相关：%Processor Time: 被处理器消耗的处理器时间数量；private bytes:这个进程不能与其他进程共享的、已分配的当前字节数。

9.分析测试结果的经验与教训
9.1经验：
1.查看用户是否全部通过，如果有失败数，查看报错信息。

2.事务响应时间是否在性能指标以内，如果大于性能指标，则降低压力进行测试。

3.吞吐率图，如果曲线有下降趋势，说明性能在下降，如果曲线在一个时间点突然下降到接近0，则系统发生了崩溃，那么服务器端产生了瓶颈，要区分是资源达到最大极限还是参数配置引起的崩溃，就要进一步分析系统资源图。

4.系统资源图重点分析测试过程中CPU和内存是否出现瓶颈；CPU如果平均利用率在95%以上，则是CPU瓶颈；内存先查看可用内存Available Mbytes的值，如果小于10%的物理内存那么是内存不足，如果值很大，那么就要看相应的进程了，查看分配的内存是否够用。此次测试中，就是tomcat的内存数不够导致了内存溢出。

9.2 教训：
1.测 试过程中得出的实际结果与预期结果不相符合时，应当深入分析具体原因，而不是失去目标的测试。此次测试过程中，发现相同的脚本相同的场景设置，在重启服务 前后测试结果差异很大。遇到这个问题时，没有进行深入分析，不但耽误了测试时间还不能很好的给以后测试带来帮助。通过柳老师和霍老师的评审，发现是脚本录 制与中间件参数配置方面引起的测试结果前后不一致。

2.学好LR工 具的使用，仅仅是性能测试的必备条件之一，需对网络、操作系统、数据库、中间件的知识进行深入学习。会工具的操作，不代表就能够做好性能测试，要对测试的 结果进行分析，还要依靠测试分析者的经验、技能和对系统的了解。此次测试过程中，在网络方面得到本部门的技术支持，解决了很多由网络造成测试无法开展的问 题。例如，由于IP与MAC地址的不一致引起的网络不稳定，致使测试数据失真，与数据库连接不稳定等，后来通过调整解决了此问题。要加强数据库性能调优方向的深入学习，懂得数据库各配置参数的调试，加强对常见的中间件产品性能调优方面的学习。

3.在测试的过程中根据用户要求的性能指标制定测试计划，同时也要站在测试人员的角度思考问题。系统可能的性能瓶颈在哪里？服务器的CPU使用是不是达到最大值？是否还有可用内存？应用服务器的状态如何？设置的JVM可用内存是否足够？数据库的状况如何？通过更换哪些设备或进行哪些调整能够提高性能？系统在长时间的运行中是否足够稳定？这样才能比较深入的开展性能测试。