【工作经历:阿里巴巴搜索技术研发中心QA ,百度新产品测试部QA】 【领域:测试分析,自动化测试,性能测试,安全测试 】 【个人定位:高级测试工程师+培训师+领域产品专家】

发布新日志

  • mysql的微秒补丁

    2012-02-10 15:55:06


    最近做一个项目的性能测试,是涉及算法相关的。整个项目由c++开发。读文件,写数据库,查询网络接口,写数据。蛮简单。

    不过发现了2个性能问题。解决过程中,折腾了不少,其中用到了一个mysql的性能排查方法,在此标注下,以备参考。


    mysql在性能profile的过程中,有很多的方法和工具,比较靠谱的一个方法,就是打开slow query log。
    但是slow log在5.1之前的版本,只能精确到1m级别。这个很鸡肋,不能满足性能profile的需要。
    所以需要进行进一步的精确。

    国外已经有人研究出了对应的方法。对mysql的代码进行修改,并做了一个补丁。
    连接参考如下


    用法很简单 
    patch patch.diff
    ./configure 
    make
    make install
    安装并启动mysql后,设置long_query_time=0  就可以开启slow query的微秒记录功能了。

    这个方法,是国外2006年搞定的,已经6年了。。汗。
    google之竟然发现被引用了无数次。

    下一步开始考虑mysql的研究学习了,发现mysql的性能问题还是蛮多的,mysql的各种机制需要深挖下。


    附上mysql官方的支持情况,有点无语。。

    Summary of Official Support

    v4.0, 4.1, 5.0: not supported; long_query_time is limited to a resolution of 1 to 10 seconds.

    v5.1 up to and including 5.1.20: not supported; long_query_time is limited to a resolution of 1 to 10 seconds.

    5.1.21+: for the value of long_query_time "the minimum is 0, and a resolution of microseconds is supported when logging to a file. However, the microseconds part is ignored and only integer values are written when logging to tables." (MySQL :: MySQL 5.1 Reference Manual :: 5.2.5 The Slow Query Log)

    6.0 up to and including 6.0.3: not supported; long_query_time is limited to a resolution of 1 to 10 seconds.

    6.0.4+: for the value of long_query_time "the minimum is 0, and a resolution of microseconds is supported when logging to a file. However, the microseconds part is ignored and only integer values are written when logging to tables." (MySQL :: MySQL 6.0 Reference Manual :: 5.2.5 The Slow Query Log)

  • ahttp_load 改进2(增加query长度)

    2009-09-26 14:14:23

    对http_load进行了又一次的改进。
    上个版本中增加了post请求,但是限于http_load原来的一些原因,请求字符串的字节数大于600的query都会被截断。
    这是个很严重的BUG。

    因为不少的应用的query都是比较长的。而且很多人都不知道这点。
    我也是把ahttp_load 交给同事使用的时候,才发现这个问题的。
    同事的query,一般都会超过2万的。

    针对这个问题,我又进行了一次修改。

    本版本增加的功能

    1、对一些瓶颈进行了修改,目前ahttp_load可支持的最大query长度为50万字节。当然还是要保证你的query不要太长。否则的话,光发送你的query。就需要耗费一定的时间了。统计出来的一些响应时间可能就相对的受到影响。最好不要超过十万个字节。
    2、增加了调试选项。可通过-d 1 去打开调试开关。加压的时候,还是不要打开。这个功能只是用来做调试用的。

    ahttp_load  -s 30 -m 1 -r 300 $utmp

    http_load_200909261352.tar.rar(30 KB)
  • http_load的未来

    2009-09-14 22:40:28

    因为修复了http_load 的时间差bug,才得以对http_load 有更多的扩展。
    http_load 只能支持1000的rate压力。-r 参数不能大于1000.
    不知道作者当初是怎么考虑的,我想可能的一个原因,是因为它的时间差有问题,导致1000以上的rate,没有办法计算时间差。它的最小时间单位是1ms。精度不够。
    但是通过读代码发现,http_load的加压机制,是不能支持太大的-r 参数的。

    对一个服务进行了加压。发现http_load 随着-r的增大,对加压越来越是力不从心了。
    我修改了上限,让rate增大到了2000,但是能支撑一万qps的服务,在http_load里,只能体现到1500。
    没有采用多线程,是http_load 的硬伤。
    http_load实现不了多线程,将始终是个小工具。成不了大气候。
    修改为多线程,是个很大的工作量,可能要伤筋动骨了,要颠覆http_load的整个机制了,、
    走的太远了,早就偏离了测试,还是重新选择工具吧。

    专注测试。不要偏离。
  • ahttp_load 改进

    2009-09-12 21:00:50

    看了看其他的代码,发现也不难,就忍不住又修改了下。
    稍微完善了下。

    1、可发送post请求
    2、修复-r bug。-r 300就是实实在在的300了。
    3、改成顺序读取。通过自测。是为了模拟线上环境。
    4、增加了一个小提示。真正开始连接的时候,会提示一下。还有其他的一些小标记。比如version的修改等。

    传到了QA工具包中。以后就可以放心使用了。

    相应的脚本不需要做改动了,原来的httpload脚本,可以不用改动,只需要把把http_load 指向ahttp_load 即可。
    发帖纪念一下,本期修改彻底完工了。

    因为修改时间较短,可能还有不少的bug,感兴趣的朋友可以一起研究。
    我会对这个工具进行持续的改进与测试。







    复件 ahttp_load_200909140050.tar.rar(12 KB)

  • 支持post,修复-r bug的http_load

    2009-09-12 19:39:37

    对http_load 的代码进行了重新研究。分析上次提到的-r bug的原因。
    上次提到是http_load 在发送请求间隔的设置上采用了毫秒,导致了-r 300实际会成为-r 333.
    今天重点研究了里面的关于时间的数据结构。进行了多次的跟踪修改,终于解决了这个问题。
    附件是在64位 redhat上编译通过的。

    两个特点。

    1、支持post请求
    2、-r bug修复。


    还有几个目标没有实现。
    1、随机读取文件,要改成顺序读取。
    2、无法处理太大的文件。采用数据池比较好。

    这两个就从长计议了。http_load的研究就暂时告一段落了。
    ahttp_load.tar.rar(30 KB)
  • 可发送post请求的http_load版本

    2009-09-12 04:40:42

    今天晚上对http_load 进行了部分的改进。
    把post支持加进去了。

    用法

    [huangysh@qa16 http_load_post]$ ./http_load
    usage:  ./http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-method 0|1 ] [-timeout secs] [-sip sip_file]
                -parallel N | -rate N [-jitter]
                -fetches N | -seconds N
                url_file
    One start specifier, either -parallel or -rate, is required.
    One end specifier, either -fetches or -seconds, is required.


    如下使用即可。
    ./http_load -method 1 -p 2 -s 10  /tmp/tmp_9589_huangysh.txt

    默认是get,只有加上了-method 1才为post请求。

    目前,正在和部门的同事对http_load 进行翻译注解,为进一步扩展做准备。

    http_load.rar(11.1 KB)



  • http_load两个bug的根源查明

    2009-09-07 00:34:44

    先粗略了浏览了一遍http_load的代码,主文件是一千八百多行。
    之前使用http_load,主要是有两个问题。

    1、http_load -r 的参数不准。
    这个原因是因为时间间隔它使用的是int类型,导致你设置的是-r 300,其实加压的实际压力是333.
    这个容易修改。
    2、文件太大读取慢。太大容易出问题。
    这是同事说的,我也不知道从什么地方得出来的。
    今天google了一下,也没有发现这个说话。
    发现他定义了一个结构数组存放所有的url,每个是5000个字节。文件的所有内容都会放进去。文件大小会有限制的,需要通过池的方式来解决了,貌似麻烦点。
    在我们公司,这个数字显然太少了。
    我使用500万行的query,占用了1.5G内存。

    3、随机读取query
    这个不是bug,有的时候,我们是不希望它随机读取的。
    希望按照原来的日志那样顺序的读取,实现模拟用户的操作。
    看了下代码,也找到根源了。http_load为了实现随机,他多写了不少代码。
    它是用心良苦了,我还要改回来,庆幸难度都不大。

    本月内完成这个任务。

  • 使用google form进行性能测试数据监控

    2009-08-19 17:54:00

    之前写过的一个simon_top脚本不够通用。监控进程信息需要依赖的东西太多。
    唯一的好处,就是可以对数据进行实时的监控与跟踪。比nmon要强一些。
    当然,nmon封装后,也可以达到这个效果的。

    编写了一个新的google_top。可以发进程的数据,直接发到google form。然后通过google form的gadget进行实时的绘图。已经实现了一部分。有待进一步完善。

    http://spreadsheets.google.com/pub?key=teymlJnnKUcm09ywuFcxksQ&gid=0

    这是示例,是公司某台服务器桑,某个进程的top基本信息。包括cpu,mem,res,virt,shr等。
    数据每隔10s发送一次,网页上的显示的数据,每5分钟会刷新一次,如果你不刷新网页的话。
    对google api了解的不是太多。但是对google chart api,google gadget api,google Visualization
     api是非常的喜欢。

    然后预定了两本书。《google api》,《google hack》。








  • lr9.0不支持vista

    2008-08-22 22:01:29

    今天的一个教训。vista的又一个让我心烦的毛病。

    录制的程序无法执行,提示0xc0000005错误。
    创建场景的后,执行出错,提示某个文件的n行有问题。
    以为是权限的问题,就关掉了user account control,结果还是不行。

    去网上搜索了一下,结果发现lr9.0不支持vista。
    我感觉我离格式化vista不远了。

    发现lr9.0确实是更新了不少东西。提出了很多的新概念。
  • 试手LoadRunner9.0

    2008-08-22 16:42:04

    从论坛上搜索到了loadrunner9的下载地址。然后下载下来了。我的系统是vista。
    现在对vista一点好感也没有。

    n多的软件不兼容,硬件不兼容,就包括我的一个读卡器。害的我不得不装一个xp。
    很多程序也应为vista的特殊限制而运行不起来,自己配置,花费了n多时间。
    因为这个系统已经装好了很多的工具,也懒的换了。

    从今天开始正式研究loadrunner,以前项目用过一次,学习过一段时间,掌握了点皮毛,现在基本上已经忘的差不多了。因为决定要重点关注性能测试,所以,就开始研究。

    loadrunner9.0在vista上因为种种vista的限制,会发生一些小毛病,比如无法录制,无法运行。
    索性就把vista的user account control给关掉了。

    新版本的界面发生了很多的变化,重要的功能才菜单还是没有变。录制格式依然是c风格的,还算满意。
    新版本扩展了很多的东西,增加了不少的支持。看来,lr又要领风骚一阵子了。

    学习计划

    1、首先看一篇用户手册
    2、利用自带例子练手。
    3、重温以前买的三本性能测试书籍。


    loadrunner除了可以进行性能测试,还可以进行很多很多扩展,比如xss检测,sql注入检测等。
    只是人们都还没有意识到这些功能。
    等使用熟练了,一定要进行一些扩展,让这个工具成为自己的又一把倚天剑。


    因为学习经历有限,性能测试只学习loadrunner。第三方工具就不研究了。阿里巴巴的人好像是还研究jmeter。对这个不熟悉。在lr没有彻底熟悉之前,不要花费时间去关注它。
    专注于一种即可,不要让自己太浮躁。

    像liangjz,qaarchite那样的牛人,是需要n年才可以做到的。

Open Toolbar