一次性能测试结果排查过程（转载）

http://www.51testing.com/?uid-13997-action-spacelist-type-blog-itemtypeid-1126

一个测试环境受到外部不预期的干扰，性能测试结果将出现不预期的数据，导致分析困难甚至错误结论。
最近碰到一个CASE，将一个sevice  插入测试环境的网站应用中，然后对比是否加入这个service的性能影响。
多台测试机器，每台机器部署多个应用，所有应用共享一个DB。

  系统架构： java + webx+ ibatis+ oracle。

        另外，这个service采用几百K的数据运行速度也在毫秒级别。
       
        呵呵，差点掉到沟沟里，特记录下。
       
一 制定测试方案

和service开发的dev 评审测试方案。 没有和网站应用的架构师核对。
被测服务器 load 已经大于 1 。


二 性能测试执行过程

选取一个post 产品的流程做性能测试脚本。性能测试数据从几百个byte-几K.
调整JAVA应用参数与生产环境同。

1) 删除用户数据
2) 删除日志
3) 重启应用
4）交替执行service上与不上场景.
5）多次执行去性能数据平均值

性能测试选择在晚上人少时执行。


三 性能测试结果分析

性能测试发现average response time，上与不上service 相差无几,都是0.13秒左右 。甚至同样并发数时，上service的response time 比不上service的response time还要低。
其他load <2 ,cpu%约20% ,iowait% <1%,内存充足都相近。这个结果似乎有点解释不通。

另外比较反常的是：average reponse time图(非graph average)上偶尔有锯齿型的到达0.2 甚至0.4的高点，尺度延续时间40多秒。average response time的 std dev（标准方差）约 0.13甚至更高。
经web page break down分析图片这个数据更加清晰可见。


经咨询网站的同事，架构师，DBA，可能多台机器上有应用定时器（quartz框架）或者DB自身定时器干扰，与网络无关。
选择关闭上述所有应用定时器以及DB层定时器后，晚上重新执行多个场景的性能测试，并手工定期检查DB执行SQL。


再分析性能测试结果，依然有锯齿型数据且性能结果且很接近之前结果，但这个数据是可控程度高的数据。
用SQL查询性能测试期间DB 日志：
select SEQUENCE#,FIRST_TIME from v$log_history
  2  where
  3  FIRST_TIME >=to_date('20090209 19:00:00','yyyymmdd hh24:mi:ss')
  4  and FIRST_TIME<to_date('20090209 23:00:00','yyyymmdd hh24:mi:ss')

发现有4个日志切换过程。

对比average reponse time拐点与日志切换时间点，部分与之吻合，但average reponse time拐点长度偏大。
经咨询每次日志切换约有20-50毫秒事务挂起。

另外部分不吻合部分，是service处理数据长度随机变化有关。

四 常见工具

再回头看看确认环境干净，参数配置预期正确的工具。

毫无疑问，好用的脑子是最强的武器。

1） OS 层面
ps ,top 看进程
ipcs    看进程间通讯
netstat 看网络连接
nmblookup,nbtstat 连接的人

sysctl,/proc  看系统参数
ulimit   系统软、硬限制

2）apache 层

httpd.conf

3) mod_jk 层
几个 property文件

4）JBOSS 层
run.conf,run.sh以及应用配置参数

另外就是检查对应启动的服务,可以借助 web-console
5） JVM 参数

6） DB 层面
oracle init file
mysql show variables

7) 其他关联服务。
如 memcached

...

从上例看到，性能测试排除干扰很重要，在系统日趋复杂的情况下需勤开口、善借外力，力争一次把事情做对、做好

阿里巴巴性能测试规划思路

1)充分利用已有性能测试脚本，做性能测试回归对比，形成性能测试结果趋势分析库
2)补充JMeterLINUX/ORACLE监控功能，补充报表统计分析功能，增强分布式脚本分发功能，规避OutOfMemory异常
3)进一步挖掘前端性能测试工具，记录生产环境页面响应时间变化趋势,利用浏览器上等图形展现框架表达趋势。另外，参考HP BAC产品开发一些补充功能
4)公司级别日志挖掘功能，以及服务器端性能监控颗粒细化，公司多个PC机器访问时间等信息充分利用，完善生产环境负载模型
5)最最重要的是，提高模拟海量数据/高并发模拟压力能力，避免系统上线性能问题。还需要利用JMX等技术开发监控JAVA服务器/apache 细颗粒的性能，
降低性能调优难度
6)性能测试人才梯队建设以及培训交流增强

大型复杂系统性能测试初步分析评估的核心思路

（1）        系统相关组件的配置文件或者设置是？：
HP-UX:kmtune或者sam
Solaris: /etc/system或者admintool
Linux:sysctl或者/proc/sys
AIX:/etc/security/或者smit
ASP.NET:machine.conf,web.conf以及IIS配置
WebLogic:startweblogic以及config.xml，http://IP:7001/console
Oracle:init.ora或者OEM
Mysql:my.cfg或者mysqladmin –variables或者mysqladmin工具

（2）        客户端与服务器端采用的语言：C/C++,Java,c#,VB,Dephi,ASP.NET/PHP/JSP。初步判断是否适合大型应用、平台移植、性能、参数配置（java –Xms? –Xmx?等）。
（3）        客户端开发采用的框架（MFC,VB,SWING/AWT/,DEPHI）。即考虑是否可以采用winrunner作为备选方案。
（4）        客户端与服务器端通信协议（socket,corba,oracle-2 tier,http….）以及同步/异步通信方式、是否采用了加密、解密算法。若采用了算法，提供源码。
若为异步通信，可否分离push/drag信息（不同端口、不同标签？）?是否可以启动多线程程序控制时长或者迭代次数。
若为SOCKET，请提供判断SOCKET收包完成的标志：
固定长度or 特定字节or变长（字段还是字段组合推算）。
（5）        客户端与服务器端连接是否为长连接？是否要求保持heartbeat信息？idle多长时间被中断？（如asp.net为20分；weblogic为10s;loadRunner generator与controller之间心跳检测为2分钟。）
（6）        若客户端与服务器端采用多协议，是否两种协议都在LoadRunner录制、支持范围。若采用socket/corba，应优先录制脚本，进一步考虑是否有必要封装成dllexport函数，供loadrunner 加载利用。
（7）        进一步了解loadrunner对该协议的多线程能力、hook处理。
（8）        采用的第三方产品性能测试？
(9) 硬件平台
(10) 数据存储分布情况

 电信网管系统编写DLL API供loadrunner调用的规范

由于性能脚本开发工具一些固有的缺陷，加上网管系统多用事件触发，压力入口存在多个，录制采用的协议相对底层(非web)，解决回放的成本高。
     故将前台用户操作部分的核心功能封装成纯C语言的dll，供loadrunner调用，具体要求：
(1)将存在度量用例响应时间的程序段（存在用户等待的地方），封装成一个 dllexport function(in 变化参数，out 结果代码,out 错误消息)函数。in参数不用二维数组、函数指针等复杂类型。多用一维数组，字符串，指针，int/long等简单类型。in参数为界面上看到的友好名称或者能轻易从数据库查询出来的值。
(2)若为触发的事件，外部调用能控制等待或者轮循的速率控制。 如sleep...
(3)对于回调的事件，有专门的函数收包，可以不审核包的内容。
(4) 对核心函数应该提供调用样例。如
init(..);
login(user,passwd.....);
getalert(...)
cofirmalert(...)  
logout(..);
注意参数都是对客户而言是友好的，非下层corba或者socket等私有key.
若后台网元传送到采集机/服务器无法模拟峰值吞吐的 ，同样有如上要求。
如何客户端主动发送的请求与服务器推送的告警所用端口分开，请说明两个端口。
若核心程序为Java包，则请封装为JAR，暴露核心功能class以及方法。   

另外，请厂家利用viso描述核心功能在采集机、应用服务器、DB之间的信息流图.

论坛]大型RAILS应用(网络考试)性能测试与调优过程

一 背景介绍

  系统为上海一家IT公司rail on ruby快速开发出来的网络考试系统。核心功能：登录、考试。考试分为html的单/多选题,flash展现的操作题

。在内部一次模拟考试中，系统曾经出现性能故障，导致无法正常做题。
   
二 系统架构分析

接到性能测试任务，第一感觉：要很注意每一个细节，包括用户行为模拟、场景设计合理全面等。

咨询了解到系统架构为: ruby+rails+ apache2.x+mysql5。

登录系统：登录web与登录的DB分开
考试系统：考试web与考试DB 集中部署在一台机器上。答一道题目即插入数据库表


三 用户行为分析

1 考试要求在 0~45分钟内考试完毕
2 多数考生一般先做选择题，再做操作题；少部分反之。
3 多数考生做完全部题目，少部分考生中途就提交结束答卷
4 题目可以回退或者选择任意一题目修改答案
5 同一个考生在提交答卷后，不能再答题

由于系统更加细致的数据没有log分析，就简单采用80-20原则随机模拟。

四 脚本开发小技巧
1  随机模拟脚本
init.c 加入 srand(time(NULL));

action.c 加入  rand() % 100；
  
2 cookie处理

服务器端检查cookie信息。
加入web_add_auto_header 确保后续每一个http请求都自动把cookie加入header

3 并发处理
由于一次性考试，故并发数没有按考试人数缩放，但考试按照一定的随机think time等待。
  
五 系统调优

主要的线索是environment.rb定义的config.log_level 生成product.log，
以及rail bench。

(一) 精简登录首页
       
1 登录：削减登录网页，很轻量级，仅仅包含Login 窗口

(二) flash下载模式变更
        原来做操作题目，该flash操作题才下载到客户端。
为了减轻并发下载flash的网络流量压力，变更为在登录成功后，客户端javascript采用ajax技术(xmlhttpquest)随机1-60秒内后台主动下载

flash试题到客户端。改变网络流量瞬间飙升的情况。

(三) apache2.0 调整httpd.conf 关键参数以及加载mod_proxy 、mod_mem_cache

1 apache httpd work mpm模式。
增加 MaxClient。

<IfModule worker.c>
StartServers         2
ServerLimit         2500
MaxClients         2500
MinSpareThreads     75
MaxSpareThreads     255
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>


2 上apache 负载均衡模块 mod_proxy

ProxyRequests off

<Proxy balancer://kaoshi>
BalancerMember http://localhost:6000
BalancerMember http://localhost:6001
BalancerMember http://localhost:6002
BalancerMember http://localhost:6003
BalancerMember http://localhost:6004
BalancerMember http://localhost:6005
</Proxy>
ProxyPass /images !
ProxyPass /stylesheets !
ProxyPass /javascripts !
ProxyPass /expert_photos !
ProxyPass /uploads !

ProxyPass / balancer://kaoshi/
ProxyPassReverse / balancer://kaoshi/
ProxyPreserveHost on


3  LoadModule mem_cache_module modules/mod_mem_cache.so加载cache模块

       CacheEnable mem /
       MCacheMaxStreamingBuffer 65536
       MCacheRemovalAlgorithm LRU
       MCacheSize 3000000
       MCacheMaxObjectCount 256000
       CacheIgnoreHeaders None
       CacheIgnoreCacheControl On
       MCacheMinObjectSize 1
       MCacheMaxObjectSize 2560000
       CacheDefaultExpire 10



(四)  rails 相关调整


1 变更默认连接器为C-based MySQL library mysql-2.7。
2  直接写SQL不用activeRecord 接口。
3  修改mogrel 服务参数

mongrel_cluster.yml

cwd: /home/www/kaoshi/current
port: "6000"
environment: production
address: 0.0.0.0
servers: 7


4 rails负载均衡


[app@b2bsearch114 controllers]$ pwd
/home/app/download/match_export/app/controllers

class ExamsController < ApplicationController
  IPS = %w(10.0.6.91 10.0.6.91 10.0.6.91 10.0.6.91 10.0.6.91 10.0.6.91)

  def host
    index = (session["no"] || 1) %  IPS.size
    render :text => IPS[index]
  end

5 rails 部署Memcached缓存模块


(五)  数据库结构以及SQL 调优

调整MYSQL配置文件、以及增加部分字段索引之后，iowati%从20%下降到0.4%
祥见
http://nnix.blogbus.com/logs/14824821.html
/bin/sh /usr/bin/mysqld_safe --user=mysql

[root@aligame etc]# vi my.cnf

[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 64M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 64M
event_scheduler=1
lower_case_table_names=1
max_connections=200
back_log=512
default-character-set=utf8

log_slow_queries
log_long_format
long_query_time=1
server-id       = 1
#innodb_data_file_path = ibdata1:1025M;ibdata2:256M:autoextend
innodb_buffer_pool_size = 1024M
innodb_max_dirty_pages_pct = 90
innodb_additional_mem_pool_size = 16M
#innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50
innodb_file_io_threads = 4
innodb_thread_concurrency = 8

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M



这 log_slow_queries,log_long_format,long_query_time=1 慢的查询语句将被打印

在目录下可见*slow.log文件记录可能有性能问题的SQL


七 小结
       
   本次rails程序从应用程序调优、APACHE配置与调优、MYSQL索引与SQL优化多个细节提升性能。
调整从最显著的一个瓶颈(apache Maxclient->Mysql SQL)开始的，一次仅调整一个。
  本次调优一个环节后，瓶颈从一个环节转移到另外一个环节。

[论坛]loadrunner的不足与jmeter用武之地

我们购买了LoadRunner 8.1 作为性能测试主流工具，商业工具确实用的蛮好的，在部门层面推行顺利。
结合实践，发现有几点相当不错：

1) LoadRunner controller运行稳定
2) 支持多个load generator 一起施加压力
3) 监控指标相对齐全
4) 性能测试结果颗粒细致
5) 预留有性能结果在monitor上的api 接口
...

  但LoadRunner是否足够完美了呢？答案：NO

1) 对汉语的编码支持问题：utf-8/gbk设置导致有时仅用英文作web_reg_find的check point

2) LoadRunner 8.1 Udp方式监控unix资源导致有断续， 呵呵，改天要电话咨询下HP有无补丁。
(LR 8.0有的)

3) 有时应用vugen 录制/回放异常退出程序

4) 最为诟病的：昂贵

5) 支持jboss/tomcat/mysql等的应用性能数据需要自己实现,实际上监控linux也无可用内存、iowait%、网络流量等指标

...

  我们把更多眼光关注开源社区，评估opensta、jmeter、webload...。 最终选取与公司主流技术平台( java+apache2+ jboss4.2 +oracle9i/10g + redhat linux)一致的jmeter做一个补充。

  对于Jmeter最为关键的几步：

1) 分析性能测试结果和loadrunner不同的原因
2) jmeter 产生压力的稳定性以及原理
3) 监控扩展能力。 linux+oracle9i+jboss+mod_jk 等这些需要支持，呵呵，否则很可能需要手工收集各个平台性能数据，造成效率低下
4) jmeter脚本调试能力，支持参数化、关联、检查点、http协议自主控制(超时、cookie、http头、是否下载non-html资源)等