一个程序猿

最近群里聊到测试，我也拿公司测试部门的一个文档分享。我们测试组4个MM，负责平时的功能测试，性能测试和安全测试。既有很萌的测试主管，又有彪悍的千杯不醉，还有海吃不胖的瘦弱女生，包括由行政转为技术的全才。

PPT主要得靠演讲人的口述才能理解，这里PPT写的也比较详尽，大家可以看出一些功能和流程上的东西。

PPT部分内容删除，包括产品业务流程图，设计敏感账号和我们一些IP信息，不过不影响阅读。

附加一句：得用WPS打开。没装WPS的可以来这里下载 http://www.wps.cn/

顺便宣传我们的产品 逍遥问问

PPT下载

其实已经有一个成形的mysql json编码的模块 http://www.mysqludf.org/lib_mysqludf_json/index.php

不过我们在使用的过程中，发现这个函数有版本兼容的问题，后看代码，发现它的json加密规则比较麻烦，没拆出来分析，就自己使用一个json类 http://sourceforge.net/projects/cjson/ 重写了一遍json_object函数。

目前在mysql-5.0.22版本上使用基本没问题，但在mysql5.5以上版本会有问题，udf接口格式好像有了变化。

mysql-5.0.22版本给出的例子是c++的代码。使用了extern语法，为了兼容gcc的语法。而我实际使用纯C环境，就抛弃了extern的语法。

udf_json源码下载

编译完成，复制so文件至公共库，然后执行以下语句：

使用 ：

PHP调用：

结果显示：

array(3) {
["id"]=>
int(2)
["intval"]=>
int(43324)
["value"]=>
string(10) “fdsfdsfdsa”
}
array(3) {
["id"]=>
int(5)
["intval"]=>
int(432432432)
["value"]=>
string(10) “fdsafdsasa”
}

mysql5.5.8对于守旧的人绝对是一种惨无人道的蹂躏。

我开始用mysql5.5.8了，被忽悠得天花乱坠，说性能提升，说主从同步迅速……

不过我是专用udf功能的，因为我常用的mysql稳定版本5.0.22官方说有点小bug，使用udf有点问题，被迫升级了5.5.8版本。

mysql5.5.8抛弃了我们钟爱的configure，而次用了cmake。

当然你要先安装cmake http://www.cmake.org/files/v2.8/cmake-2.8.3.tar.gz

cmake安装简单，tar后make && make install 搞定。

mysql5.5.8到官网下载 http://dev.mysql.com/downloads/mirror.php?id=399302#mirrors

tar出来，就找不到configure了，不过官方提供了高仿configure的转换脚本，不过神马都是浮云，自己折腾脚本吧

然后make && make install就行。

剩下的事情就跟老版本的一样了，不过我编译的时候没有成功安装 mysql_install_db 脚本，自己写了一个，也算成功完成任务了。

通过观察，大部分的dz论坛在数据量发展到一定程度，在线人数逐渐提高后，首先锁表的是sessions，这个表我已经写过多种优化的方式，不外乎寻找一些比mysql负载性能好的程序来代替这部分工作。但时间长了，随着在线人数继续增加，那个附加的程序也会面临瓶颈。提高硬件性能和软件性能固然能提高负载，但一旦到瓶颈，必须想其他的方案。

硬件和简约的程序能提高性能，在大数据量下，算法的优势就能体现出来了。

顺便提一下主从：很多人认为主从可以解决问题，其实未必。设想一主多从结构，假如主库写压力很大，那同样压力会同步到从库，会造成N个从库压力同时很大。事实上从库压力会小于主库，因为主库是多进程写，而从库是单进程写， 但总的来说，执行的语句不会少。所以，主从这种结构在一定情况下也就失去了优势。（在硬件资源充裕，压力不是很大的环境下，这种问题发生较少，在硬件条件比较差的一些环境下，这种瓶颈很容易表现出来）

这里拿discuz7的posts表举例，摆脱主从结构，硬件比较差，表很大，10G以上。

一个负载大的dz论坛，在线人数多，又比较活跃，那posts表的压力肯定不会小。在一个回复比较频繁，存储引擎使用myisam的posts表，锁表是经常发生的，我所遇见的问题发生的环境为：数据库单点，无主从，io压力中等。posts表频繁锁表，而造成查询排队，查询速度骤然下降。

在不提升硬件的情况下，要想提速，显然是比较困难的，大量的文本数据装入memcached显然也不合适。所以，这个问题我用优化数据存储的角度对数据表进行了改造。

TIPS：同样100M带宽的集线器和交换机，交换机的吞吐性能远远高于集线器，原因在于：交换机建立专有通道，避免了冲突。

而在mysql中，锁表可以形象描述为冲突了，读写冲突了。但如果我们分表，把读写分散，也许会好点。

分表规则：按照tid进行hash，分散到16个表中。

假设，一读一写，两个操作，同时进行，那么他们撞在一起的几率就是1。如果分为两个表，那么他们撞在一起的几率就是1/2 = 0.5,用一个函数来表示，就是F(x)=1/x ，显然，分的表越多，冲突的机会越小，锁表的几率就越少。即时锁表，影响的也只是1/x的数据，不会对所有的用户造成影响。

数据模型解释：如果是绝对同步发生，几率应该是 F(x)=1/((x-1)*x)，但在计算机里，无论两个操作时间间隔多小，在cpu时间片上都是顺序执行，因为，函数我认定为：F(x)=1/x。

以上用数学的方式解释了算法优化对性能的提升。实际上，通过对逍遥论坛的用户行为统计：posts表95%以上的操作都是在读写，搜索和管理占小部分。

补充一种分表算法：在discuzX里，后台启用了分表，我没有细看，大概是把表按照时间段或者其他条件分开。我猜测，作者本意是拆分老数据，主表只留最新数据和一些命中高的数据。这种方式可以起到一定效果，但根据统计，大部分用户习惯浏览回复最新帖子，因此，大部分的读写还是定位到了一张表，也就是没有彻底解决读写冲突的问题。
还有一个朋友使用的是顺序分表，500w个pid一张表，但这个方法同上个方法，没解决冲突问题。
所以，在他的基础上，我考虑出按照tid进行hash分表的方案。

说到这里，分表又给我们带来了麻烦，有些查询并不能用tid主键进行定位，这里我用了mysql合并表，这个合并表可以合并16个分表，成为一个大表进行查询，而表名依然用原始的表明，这样，dz中原来的功能就不受影响了。

此方案已经实现，我用的新老数据+分别hash的方式，即32张表存储posts数据的方式。但未做压力测试。最近努力学习loadrunner使用，这个压测马上就可以进行了。

AB库，车子默认在B库内。

1、B库到考试初试地点：前进->右杆进入右边第一个盲区（两块玻璃中间的盲区），右打轮一圈半，待车头变正，停止。
2、开始考试，帖库：看车后窗户，缓行，中杆（AB库中间的杆）进入右后盲区（驾驶室右后角的盲区），右打轮两圈打满，倒行，后窗户右侧立柱跟中杆重合后，左打轮一圈，倒行，中杆到右后盲区跟右侧立柱中间的位置，右打轮一圈打满，看左倒车镜，出现A库左后杆后，逐渐调整车子对准A库后边左右杆中间，右打轮两圈，方向盘打正，倒行，待车子后侧将近后侧的时候，停车，帖库完成。
3、移库：右打轮两圈打满，前进，待中杆移动到将近左倒车镜左数1/3的时候，停，左打轮四圈打满，前进，待车头打正的时候停止，如果车头不到前边线，可适当前进，右打轮四圈打满，倒行，视线看准后窗户立柱左边的立柱并且瞄准车后边左侧第二颗铆钉与第一颗铆钉中间，B库右后杆移动到第二颗铆钉上，停车，左打轮四圈打满，看车头，倒车，待车头摆正，停止，右打轮两圈，方向盘打正，前进，并且适当调整车子在车库中央，然后倒车，车子后边接近后边线，停止。
4、出库：左打轮一圈，前进，从A库出去，看车子右后角，将近出线的时候，左打轮一圈半，带车头摆正后，停止。
5、倒库：A库左杆刚出左边第一个盲区（左边两块玻璃中间的盲区），停止，左打轮两圈打满，倒行，待AB库中间的杆出线在后盲区后，后盲区最下边的边与杆相切，停止，右打轮一圈，继续倒行，待中杆第二次与后盲区最下边的杆相切，左打轮一圈打满，看右倒车镜，待B库右后杆出线在右倒车镜中，看左右倒车镜后边的杆线，调整车子摆正，倒车，待车头离前边线两米左右，停车。

考试完毕。必须6分钟内完成，不得压线，不得撞杆，不得违法步骤。

http://www.zyue.com/n/BU83/na70809.html 皮卡科目二蝴蝶桩过关技巧配图详解

http://teli.blog.hexun.com/36153356_d.html 科目二考试内容及技巧皮卡怎样定点停车，上坡起步，侧方位，单边桥，过圆饼

loadrunner下的mysql c api

一个很简单的模拟用户访问论坛帖子的loadrunner测试脚本

最近跟测试组学习loadrunner的使用，测试组的姑娘们习惯用界面进行操作，而习惯linux平台使用的我很多功能都使用代码来实现了。

最近用loadrunner写了一个模拟社区用户压测论坛数据库的一个脚本，进行数据库的压力测试和优化工作。

用户行为分析：

在社区中，看帖的人是发帖人的10倍以上，而看帖人大概80%以上都在看新帖，20以下的用户有挖坟行为。

因此，设定如此的比率：每11个用户，1个发帖，8个看最近30%的帖，两个看老的70%的帖。

我的论坛帖子回复表大概是：973505个帖子的回复，两千多万的回帖。

根据这些数据，配合mysql的c api，写如下脚本:

注：脚本的my_mysql_insert()函数是有问题的，多线程下有一个资源符没处理好，因为还不太了解loadrunner的线程机制，所以留下了一个bug。

在做完这个脚本后，我发现我们测试机性能都不错，很难在一个5G大小的单表上主键查询造成很大的压力，所以，计划把dz论坛架设，用php+mysql真实环境下进行压测，这样可以顺便练习http函数下的loadrunner编程。