1
纵向划分3颗子树:vugen,controller,monitor。优先学习vugen脚本开发以及调试。
横向划分为2层:基础知识以及高级应用。
2 基础知识
2.1 Loadrunner工具使用
2.1.1 建议学习路径
Vugen开发脚本(函数使用)->controller场景设置->monitor增加计数器
2.1.2 Loadrunner 认证
2.1.3 Vugen常用增强函数
增加事务:lr_start_transaction/:lr_end_transaction
检查点: web_reg_find
关联:
日志:
选项设置: web_set_timeout
http header: web_add_auto_header
以及更改runtime setting。
2.1.4 Loadrunner 架构图
概览图
2.2 Html/http协议
HTML 4.01 Specification:
http://www.eygle.com/digest/2006/12/html_xml_and_internet.html
对性能测试而言,META http-equiv控制http头、浏览器行为,故最为重要。
http协议:
http://www.faqs.org/rfcs/rfc2616.html
客户端发送请求:
服务器响应:
2.3 C 语言基础编程
Loadrunner常用的c函数主要集中在内存分配/释放、字符串操作、文件读写。
如: malloc/free
2.4 Linux 性能分析初步
核心指令:
Top
Sar
Vmstat
Iostat
Sar
/proc文件系统
分析经验性步骤:
首先查看 CPU 使用情况,按照诊断 CPU、内存或磁盘瓶颈的指导进行操作。对于下面的每个步骤,查找一端时间内的趋势,从中收集系统运行性能较差时的数据。另外,只有将这些数据与系统正常运行时收集的数据进行比较时才能进行准确的诊断。
步骤 1
# sar -u [interval] [iterations]
(示例: sar -u 5 30)
%idle 是否很低? 这是 CPU 未在运行任何进程的时间百分比。 在一端时间内 %idle 为零可能是 CPU 瓶颈的第一个指示。
不是 -> 系统未发生 CPU 瓶颈。转至步骤 3。
是 -> 系统可能发生了 CPU、内存或 I/O 瓶颈。转至步骤 2。
步骤 2
%usr 是否较高? 很多系统正常情况下花费 80% 的 CPU 时间用于用户,20% 用于系统。其他系统通常会使用 80% 左右的用户时间。
不是 -> 系统可能遇到 CPU、内存或 I/O 瓶颈。转至步骤 3。
是 -> 系统可能由于用户进程遇到 CPU 瓶颈。转至部分 3,部分 A, 调整系统的 CPU 瓶颈。
步骤 3
%wio 的值是否大于 15? (不同os有不同的阀值)
是 -> 以后记住这个值。它可能表示磁盘或磁带瓶颈。转至步骤 4。
不是 -> 转至步骤 4。
步骤 4
# sar -d [interval] [iterations]
用于任何磁盘的 %busy 是否都大于 50? (请记住,50% 指示一个大概的 指南,它可能远远高于您系统的正常值。在某些系统上,甚至%busy 值为 20 可能就表示发生了磁盘瓶颈,而其他系统正常情况下可能就为 50% busy。)对于同一个磁盘上,avwait 是否大于 avserv?
不是 -> 很可能不是磁盘瓶颈,转至步骤 6。
是 -> 此设备上好像发生了 IO 瓶颈。
转至步骤 5。
步骤 5
系统上存在磁盘瓶颈,发生瓶颈的磁盘上有哪些内容?
原始分区,
文件系统 -> 转至部分 3,部分 B,调整发生磁盘 IO 瓶颈的系统。
Swap -> 可能是由于内存瓶颈导致的。
转至步骤 6。
步骤 6
# vmstat [interval] [iterations]
在很长的一端时间内,po 是否总是大于 0?
对于一个 s800 系统 (free * 4k) 是否小于 2 MB,
(对于 s700 系统 free * 4k 是否小于 1 MB)?
(值 2 MB 和 1 MB 指示大概的指南,真正的 LOTSFREE 值,即系统开始发生 paging 的值是在系统引导时计算的,它是基于系统内存的大小的。)
不是 -> 如果步骤 1 中的 %idle 较低,系统则很可能发生了 CPU 瓶颈。
转至部分 3,部分 A,调整发生了 CPU 瓶颈的系统。
如果 %idle 不是很低,则可能不是 CPU、磁盘 IO或者内存瓶颈。
请转至部分 4,其他瓶颈。
是 -> 系统上存在内存瓶颈,转至部分 3 部分 C,调整发生内存瓶颈的系统。
2.5 Windows 性能分析初步
同windows perfmon。
同样集中在 cpu,内存,io,网络上。
一般经验值:
网络
冲突率: <1%
Packets Received Errors < 1%
I/O:
Disk Time %
Avg. Disk Bytes/Read +
Avg. Disk sec/Transfer <0.3 sec
队列长度:Queue Length <2
内存
Server -> Pool Paged Failures indicate that either physical memory or a paging file is near capacity.
Server -> Pool Nonpaged Peak shows the maximum number of bytes in nonpaged pool the server has had in use at any one point. Indicates how much physical memory the computer should have.
处理器
利用率 <85%
每个CPU队列长度<2
Context Switches/sec <5000次 或者<5% of total threads
3 高级应用
3.1 性能建模
从business layer、function layer、session layer、customer layer出发,借助日志分析工具挖掘系统负载模型、用户行为模型。
Mercury End User Management 正是一个从 client 视觉出发的业务监控解决方案。
3.2 网络嗅探器
如ethreal,fiddler,以及 http debuger工具,诊断网络问题。
3.3 Loadrunner troubleshooting
各个环节都可能有问题。 (client,通信,服务器)
经验性步骤:
诊断vugen脚本、loadrunner场景设置、客户端硬件资源是否充足
判断服务器端各层是否达到资源上限
借助ethereal等网络嗅探器判断c/s通信问题
3.4 Linux性能分析与调优
深入了解:
进程/多线程编程
同步机制
Gdb 调试core
内核参数
3.5 Windows性能分析与调优
Windows 其他计数器
3.6 C语言调用dll 扩展测试脚本
Dll编写格式:
如
int
{
}
.def文件
EXPORTS
loadrunner调用dll函数:
lr_load_dll("my.dll");
3.7 Apache/jboss/weblogic/oracle性能优化
参见各个产品tuning 文档
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
http://httpd.apache.org/docs/1.3/misc/perf-tuning.html
http://edocs.bea.com/wls/docs81/perform/
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming
http://www.jboss.org/index.html?module=bb&op=viewforum&f=121
3.8 计算机性能评测研究方向
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
参见 http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html
3.9 Mercucy performance center
http://www.mercury.com/us/products/performance-center/
4 性能测试书籍
《Microsoft .NET Web应用程序性能测试》
《软件性能测试过程详解与案例剖析》
《WEB性能测试实战》
《J2EE性能测试》
《LoadRunner性能测试实战》
5 测试网站