赞
踩
1.假设表
test_a 商品表 有1000个商品
CREATE TABLE `test_a` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
`user_id` BIGINT(20) UNSIGNED NOT NULL DEFAULT 0 COMMENT '用户id',
`goods_sn` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '包裹号',
`goods_id` BIGINT(20) UNSIGNED NOT NULL DEFAULT 0 COMMENT '商品id',
`add_time` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '添加时间',
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试表';
test_b 商品额外 属性
CREATE TABLE `test_b` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
`goods_id` BIGINT(20) UNSIGNED NOT NULL DEFAULT 0 COMMENT '主键',
`price` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '价格',
`add_time` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '添加时间',
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试表';
CREATE TABLE `queue_order_detail` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
`goods_id` BIGINT(20) UNSIGNED NOT NULL DEFAULT 0 COMMENT '主键',
`description` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '描述',
`add_time` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '添加时间',
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测试表';
简单的生成1000条数据:
for ($i=0;$i<=1000;$i++) {
$add = array("goods_sn"=>"test".$i,"add_time"=>time());
M("test_a")->add($add);
}
for ($i=0;$i<=1000;$i++) {
$add = array("goods_id"=>$i+1,"price"=>"","add_time"=>time());
M("test_b")->add($add);
}
多次查询:
$a = M("test_a")->select();
foreach($a as &$v) {
$b = M("test_b")->where(array("goods_id"=>$v['id']))->find();
$v['price'] = $b['price'];
}
dump($a);
ab压测-本地简单的跑个接口看看压测结果对比下:模拟100个并发 ,总共1000次请求
ab -c 100 -n 1000 http://localhost:84/index.php/Test/test
-c并发数 -n 总请求数
一次查询:
$a = M("test_a")->select();
$b = getFiledData(array(),M("test_b"),"goods_id");
foreach($a as &$v) {
$v['price'] = $b['price'];
$v['price'] = $b[$v['id']]['price'];
}
dump($a);
压测结果:
a.可以看出cpu以及吞吐率,接口响应时间有明显的区别,所以开发过程中要避免多次查询,
在一次性查询的数据不是很大的情况下,必须用批量查询一次性查出来再做处理。
b.那么更新新增的情况就更不用说了
mysql慢了为什么导致web的cpu升高呢?因为查询慢了cpu处理的请求结束的慢了,
其他请求只能等cpu了,所以变高了
比如压测并发的时候,同时用浏览器打开页面,已经发现 压测type=1的时候,另开浏览器打开已经很卡了。。
补充一个接口响应时间的日志elk,还有个疑问 ab测试的结果???咋不准啊
压测结果的理解:
一个人并发20条,nginx日志每个接口的相应时间为0.07秒 ,但是这些接口是并发返回的,所以这10条记录的总共消耗的时间 肯定小于 0.07*20 = 1.4s,
ab测试结果:实际的并发完成时间是 0.4s,压测结果就认为 每条接口平均时间 0.4s/20 = 0.02s — 感觉这种测试方式有问题???所以压测的理解是服务器每秒能处理多少个
换个方式理解 20条是20个人每个人并发一条,总共也需要 0.4s处理完。对于每个人来说,这一次请求的花费的时间在0.08s-0.4秒之前,20每个人面对电脑发请求,都是0.08-0.4秒完成,但是对应服务器而言。0.4秒处理了20个请求,即平均1秒能处理
0.4s 1s
20 x
x=50 每秒能处理50个请求,就是说这种接口一秒钟能处理50个,吞吐率50个/s
假设总共也花费了0.08s,那么
0.08 1s
20 x
x = 250 每秒钟能支持250个 250/s
56s 1s
5000 x
x=89
这个压测的结果可能要抛开nginx日志的时间来看了–主要一秒钟能处理多少个请求
这个ab压测可以这么理解 -c表示200个并发 -n表示总共1000个请求
瞬间200个请求上去,然后继续200个这样,直到总共请求了1000个
最后的结果表示200个并发在多长时间之内返回-以及换算成吞吐率每秒能处理多少个
这么理解就行了,你只要看200个并发 500ms内返回咋样,nginx日志越快肯定,这个越快,不过我这个服务器1核,并发200的时候,type=1跟type=2的差不多了好像
这下理解了吧老哥
画个图研究下:服务器是并发返回的,最快0.08s,几个接口都返回了,
ab.exe -c 200 -n 1000 http://175.27.190.125:81/get.php?type=2
压测问题 200并发,吞吐率type1跟type2差不多,不知道为啥,可能瓶颈到了吧?
压测50的时候,type2的效果明显
注意cpu使用率跟负载的关系
并发跟吞吐率的概念是不一样的,只要关注每秒钟能处理多少请求就行了,tps/s
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。