纵向划分3颗子树:vugen,controller,monitor。优先学习vugen脚本开发以及调试。html
横向划分为2层:基础知识以及高级应用。web
Vugen开发脚本(函数使用)->controller场景设置->monitor增长计数器apache
http://www.cnblogs.com/jackei/archive/2006/10/20/534684.html编程
更多见windows
http://www.51testing.net/BWF_DIY/mercury/mercury_051107_1.htm浏览器
http://www.51testing.net/BWF_DIY/mercury/mercury_060104_11.htm性能优化
增长事务:lr_start_transaction/:lr_end_transaction服务器
检查点: web_reg_find网络
关联: web_reg_save_param ,web_set_max_html_param_lensession
日志: lr_error_message,lr_log_message, lr_output_message …
选项设置: web_set_timeout
http header: web_add_auto_header
以及更改runtime setting。
概览图
详细架构图:
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
客户端发送请求:
服务器响应:
Loadrunner经常使用的c函数主要集中在内存分配/释放、字符串操做、文件读写。
如: malloc/free
Sprintf/strcmp/strlen/
Fopen/fread/fwrite
核心指令:
Top
Sar
Vmstat
Iostat
Sar -n DEV
/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,调整发生内存瓶颈的系统。
同windows perfmon。
一样集中在 cpu,内存,io,网络上。
通常经验值:
网络
网络利用率阀值没有统一。 <30% or 80%?
冲突率: <1%
Packets Received Errors < 1%
I/O:
Disk Time % <90%
Avg. Disk Bytes/Read + Avg. Disk Bytes/Write <20K
Avg. Disk sec/Transfer <0.3 sec
队列长度:Queue Length <2
Avg. Disk sec/Transfer <18 milliseconds
内存
Available Mbytes >25%
Page in+out <20 次
内存泄露以及错误:
Pool Nonpaged Bytes : an increase of 10 percent or more from its value at system startup。
Server -> Pool Nonpaged Failures shows the number of times allocations from nonpaged pool have failed - indicates that the computer `s physical memory is too small. 应为0
Server -> Pool Paged Failures indicate that either physical memory or a paging file is near capacity. 应为0
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
从business layer、function layer、session layer、customer layer出发,借助日志分析工具挖掘系统负载模型、用户行为模型。
Mercury End User Management正是一个从client视觉出发的业务监控解决方案。
如ethreal,fiddler,以及 http debuger工具,诊断网络问题。
各个环节均可能有问题。 (client,通讯,服务器)
经验性步骤:
诊断vugen脚本、loadrunner场景设置、客户端硬件资源是否充足
判断服务器端各层是否达到资源上限
借助ethereal等网络嗅探器判断c/s通讯问题
深刻了解:
进程/多线程编程
同步机制
Gdb 调试core
内核参数
Windows 其余计数器
Dll编写格式:
如
int __stdcall lr_getLinuxIOwait_end()
{
clnt_destroy(clnt);
}
.def文件
EXPORTS
lr_getLinuxIOwait_end @3
loadrunner调用dll函数:
lr_load_dll("my.dll");
参见各个产品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
Ø 相关理论研究(泊松分布、排队论、MaKov模型、Monte carlo模拟、自类似理论)
Ø 负载特性Workload Characteristic的研究(Commercial Workload/ Technical Workload)
Ø 基准程序Benchmark的研究
Ø 性能指标的研究(全生命周期/高效能/TPO Total Productivity Ownership/SLA Servcie Level Agreement/QoS)
Ø 模拟器的研究(SimpleScalar/SimOS/SandOS)
Ø 测试系统的研究(Benchmark Factory/ServerScope/Benchmark Studio/LoadRunner/Forecast toolset)
Ø 监控系统Perfomance Evaluation(Intel Vtune/ EMon/ TeamQuest Lite/ ServerScope-Monitor/ Grid-View)
Ø 性能评测与体系结构的结合(Computer architecture analysis using workloads)
参见 http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html
http://www.mercury.com/us/products/performance-center/
《Microsoft .NET Web应用程序性能测试》
《软件性能测试过程详解与案例剖析》
《WEB性能测试实战》
《J2EE性能测试》
《 LoadRunner性能测试实战》
http://www.51tester.cn
转载自:http://www.ptesting.com/archives/167.html