【工作经历：阿里巴巴搜索技术研发中心QA ，百度新产品测试部QA】
【领域：测试分析，自动化测试，性能测试，安全测试 】
【个人定位：高级测试工程师+培训师+领域产品专家】
发布新日志
-
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)
查看(539)
评论(0)
收藏
分享
管理
-
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)
查看(604)
评论(0)
收藏
分享
管理
-
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的整个机制了，、
走的太远了，早就偏离了测试，还是重新选择工具吧。
专注测试。不要偏离。
查看(1116)
评论(2)
收藏
分享
管理
-
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)
查看(571)
评论(0)
收藏
分享
管理
-
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)
查看(1442)
评论(3)
收藏
分享
管理
-
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)
查看(7671)
评论(7)
收藏
分享
管理
-
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为了实现随机，他多写了不少代码。
它是用心良苦了，我还要改回来，庆幸难度都不大。
本月内完成这个任务。
查看(1186)
评论(0)
收藏
分享
管理
-
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》。
查看(459)
评论(0)
收藏
分享
管理
-
2008-08-22 22:01:29
今天的一个教训。vista的又一个让我心烦的毛病。
录制的程序无法执行，提示0xc0000005错误。
创建场景的后，执行出错，提示某个文件的n行有问题。
以为是权限的问题，就关掉了user account control，结果还是不行。
去网上搜索了一下，结果发现lr9.0不支持vista。
我感觉我离格式化vista不远了。
发现lr9.0确实是更新了不少东西。提出了很多的新概念。
查看(292)
评论(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年才可以做到的。
查看(965)
评论(0)
收藏
分享
管理
