淘宝商城(天猫)高级技术专家.3年研发+3年性能测试调优/系统测试+4年团队管理与测试架构、研发系统实践. 新舞台新气象, 深化测试基础架构及研发架构,希望能在某个技术领域成为真正的技术大牛。欢迎荐才http://bbs.51testing.com/viewthread.php?tid=120496&extra=&page=1 .邮件: jianzhao.liangjz@alibaba-inc.com,MSN:liangjianzhao@163.com.微博:http://t.sina.com.cn/1674816524

性能测试执行检查列表

上一篇 / 下一篇  2007-08-12 21:22:15 / 个人分类:loadrunner性能测试经验

 1  性能测试执行检查概览

从各个层面考虑。

  • 1) 需求、方案内容以及形式检查
  • 2) 系统各个组件检查
  • 3) Loadrunner场景设置、脚本、监控指标、负载生成机的核对

•2         核对《性能测试需求》

•2.1       用例选取

至少包含关键业务、最常用的用例,用例步骤为用户常用访问路径

建议用例包含部分用户放弃或者失败的操作步骤

确认负载建模数据来源

•2.2       并发用户数需求

并发用户数一般为在线活跃用户的15~25%间。

用户归类是否合理、访问路径是否典型等work load

•2.3       响应时间需求

结合web 8 minute rule对比

•2.4       服务器资源利用率需求

应低于业界同行认可的资源阀值。

•2.4.1    Unix

Load:  < 5* cpu颗数

Cpu%: <80%

内存:swap-in/out =0

网络%: collision rate =0

•2.4.2    Windows

网络:

   网络利用率阀值没有统一。  <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 =0

处理器:

利用率 <85%

每个CPU队列长度 <2

Context Switches/sec <5000次 或者<5% of total threads

•2.4.3    应用特有指标

•3         核对《性能测试方案》

•3.1       测试策略

  • 1) 场景与用例应有针对性地攻击系统性能薄弱环节,条件允许的话建议定位出负荷过大的临界点
  • 2) 测试实现手段成本效益分析,确认技术与时间可行性。对于加解密、随机码等技术环节,应尽早技术试验确认测试可行性。
  • 3) 总吞吐率确保至少高于现网生产环境负载或者未来运营负载,充分考虑未来3年负荷增长
  • 4) 至少一个运行长于8小时的峰值场景甚至overload场景,以便挖掘内存泄露
  • 5) 分析测试环境与生产环境(硬件、参数、数据量)差异,确认测试方案的能力与缺陷。尽量往生产环境靠拢(缩放或者mirror)。如果测试环境与生产环境差异太大,则必须分析性能测试风险,同时在性能测试报告中注明该限制
  • 6) 针对不同的应用,测试重心应略有侧重。 如EAI 侧重数据交换,数据仓库侧重SQL查询语句等
  • 7) 建议有一个大量vuser的场景,确认无connections限制及模拟现实的离散访问。
  • 8) 需求以及方案经过项目经理与开发工程师确认

•4         核对操作系统

Alibaba目前大部分系统采用linux os,少数数据库部署在aix上。

•4.1       硬件配置

Linux:

处理器:Cat  /proc/cpuinfo

内存:Cat  /proc/meminfo

       网络:mii-tool -v

    硬盘: mount 确认 -> scsi/sda -> /proc目录下找到硬盘厂家 ->查到读写能力指标

•4.2       版本号

Uname -a

Cat  /etc/ redhat-release

•4.3       系统参数

Sysctl -a

Ulimit  -a

建议测试时ulimit  -c unlimited启动core dump生成选项

•4.4       进程

确认portmap、rpc.rstatd进程存活

应关闭无关的应用进程,以免干扰资源利用率数据

•4.5       端口

开放111端口

•4.6         分区硬盘空间

Df  -m 确认增长最快的分区有足够的余量。

•5         核对数据库

Alibaba应用大部分部署在oracle上。目前最流行的版本有oracle 9i与oracle 10g。一般情况下,由系统管理员负责监控数据与性能变化。

•5.1       版本号

•5.2       部署模式

确认部署模式为 dedicated or  share

•5.3       配置参数

InitSID.ora 或者动态配置的文件参数,确认日志归档模式、SQL跟踪等。

•5.4       基础数据与测试数据尺寸

利用SQL 语句统计基础数据,同时确认测试数据准备情况

对于测试后产生大量中间数据的场景,每次测试完毕应清除中间数据

•6         核对应用服务器

•6.1       Jboss

•6.1.1    版本号

•6.1.2    部署模式

•6.1.3    配置参数

•6.2       Weblogic

流行版本weblogic8.1 ,weblogic9

•6.2.1    版本号

http://IP:7001/console查看

•6.2.2    部署模式

采用开发模式 or 部署模式

是否采用集群

•6.2.3    配置参数

分析启动配置文件startWebLogic.sh以及关联的配置文件setEnv.sh、config.xml,重点关注线程数、backlog长度、是否采用native io等。

•6.3       Resin

•6.3.1    版本号

•6.3.2    部署模式

•6.3.3    配置参数

•7         核对web 服务器

•7.1       apache

•7.1.1    版本以及编译模式、模块

版本:httpd -v

编译模式:httpd -V

模块:httpd -l

•7.1.2    配置参数

主要配置文件为:Httpd.conf。

主要确认进程模型、 maxclient、timeout、是否采用SSL协议等等。

•7.1.3    DSO模块版本

察看loadModule 配置项核对 DSO。

•7.1.4    日志级别及文件

一般, 错误日志: logs/error_log,访问日志:access_log

注意清理日志,防止过度膨胀。

•7.1.5    是否采用Cache模块

前端是否采用 squid或者其他cache服务。

•7.1.6    内容

是否包含图片,javascrīpt,applet等non-html资源。

•7.2       tomcat

•8         核对应用系统

•8.1.1    版本号

•8.1.2    核心功能可用性

•9         审查性能测试工具

•9.1       审查LoadRunner组件

•9.1.1    场景设置

  • 1) 场景模式面向目标/手工是否与方案相符合
  • 2) Pacing
  • 3) Think-time (是否有必要忽略)
  • 4) Download non-html resource (视应用是否应当下载)
  • 5) Simulate a new user on each iteration(登录录制于action.c时应selected)
  • 6) Continue on error
  • 7) 存放测试结果目录所在磁盘空间是否足够

•9.1.2    Web协议脚本

  脚本流程与用户访问路径一致

  • 1) 关键业务事务须有检查点(如web_reg_find)
  • 2) 参数化数据及设置与业务需求预期 (随机、unique)
  • 3) 必要的地方增加关联 (web_reg_save_param)
  • 4) 必要的地方增加http header (web_add_auto_header)
  • 5) 必要的地方增加超时设置 ( web_set_timeout)
  • 6) 必要的地方增加随机数 (srand,rand)

•9.1.3    Socket协议脚本

贸易通客户端与服务器交互采用socket协议录制。

  • 1) 脚本行为与用户访问路径一致
  • 2) 确保可以正确收发网络包

•9.1.4    监控指标

各个服务器以及负载生成机都应该监控。至少包含cpu,mem,io,network资源指标。

•9.1.4.1       unix

建议监控指标至少包含

  • 1) Average load
  • 2) Collision rate
  • 3) Cpu utilization
  • 4) Disk traffic
  • 5) Incoming packets error rate
  • 6) outcoming packets error rate
  • 7) page in rate
  • 8) page out rate
  • 9) swap in rate
  • 10) swap out rate

若如上指标还无法满足定位瓶颈需求,则弃用loadrunner monitor监控,而采用sitescope监控更多指标( ssh+ linux command) 。一般额外监控的有

可用内存、Iowait%。

              对于对比性能测试,确保服务器资源有一定余量以满足Utilization Law定律。

•9.1.4.2       windows

建议监控指标至少包含

  • 1) Process time%( process_total)
  • 2) Process queue length(system)

  • 3) Available mbytes( memory)
  • 4) Pool nopaged bytes (memory)
  • 5) Pages sec (memory)
  • 6) Pool nonpaged failures(system)

  • 7) Disk time% (physicaldisk _total)
  • 8) Avg. disk queue length (physical _total)

  • 9) Bytes total/sec (network interface)

•9.1.5    负载生成机

  • 1) Loadrunner结果存放临时目录: temporary storage location 所在分区空间足够大
  • 2) 确保测试执行过程中各项资源充足,可发出足够的请求压力
  • 3) 建议关闭防火墙、反病毒等软件
  • 4) 确保开放端口 54345以及另一个动态端口
  • 5) 确保进程 (m)mdrv.exe,lr_bridge,magentproc.exe(作为进程)/magentservice(作为服务),r_host_balancer.exe等进程存活
  • 6) 若安装loadrunner时选择:Manual log in to the Load Generator
  • 7) 时间与服务器同步。若要求严格同步,则建议安装ntp服务。

目前alibaba仅采用windows平台作为load generator。

•9.2       审查自主研发测试工具

•9.2.1    评估架构与能力、缺陷

评估压力生成方式、限制条件、负载确认手段、结果收集与统计能力等

•9.2.2    审查源码

开发工程师应提供测试工具源码,性能测试工程师检查变量上限,如socket数,线程数等是否超过OS限制。

•10    分析预测试性能测试结果合理性

•10.1  Loadrunner测试结果

分析测试结果是否符合排队网络、概率分布等核心原理

负载生成机资源是否有余量

output windows是否有connection refused、timeout等错误

尽量确保测试结果是可重现的

•10.2  OS系统操作错误

察看系统日志是否存在错误,一般在 /var/log/messages

•10.3  数据库错误

Alert*.log是否有ora-X 等错误

是否检测到死锁

•10.4  应用服务器以及web服务器错误

检查是否存在core dump

检查日志是否存在 Exception ,Error,Warning等


TAG:

Quality Trackers 引用 删除 liyun100   /   2013-09-23 10:11:16
5
引用 删除 TONYWON   /   2009-04-09 14:09:01

通俗点哈
 

评分:0

我来说两句

Open Toolbar