新手问题 压力测试后的迟钝反应

jay_li · 2016年03月18日 · 最后由 msg7086 回复于 2016年03月23日 · 3019 次阅读

测试的项目基于 Sinatra,Web 服务 Unicorn,数据库 MySql(阿里云),环境 CentOS,内存 8G,磁盘空间 1T(挂载)。

过去几个月运行良好,由于近期要内部推广,就想压力测试一下,看代码的性能表现。

ab  -c 10 -n  1000  url/api-path

下午(15:40)测试(运行环境)后就开始分析代码,也没去看服务器怎么样(平时的责任心去哪啦),刚才(18:13}就接到客户电话,说客户端访问不了数据。

远程登录,重启项目代码,成功,但访问(域名,IP:端口)很慢。

切换至 Root,重启 Nginx,访问依然很慢,甚至在服务器内部 Curl 访问 localhost 依然很慢(困惑)。

检查内存、cpu、磁盘,一切正常,继续不知所措(请问此时该怎么继续调试下去),就把项目的日志删了(41M),Nginx 日志文件夹没动(1.4M)。

此时已经过去十几分钟,浏览器依稀可以解析域名,但样式文件没加载完整。

查看 Unicorn 内存占用,正常。

刷新浏览器,访问正常,估计是上次访问成功,这次 304 吧,登录进去,很慢,但算有响应了。杀掉进程,重启 Unicorn(重复了几次),好像一切正常了。

但客户端一登录,就又僵尸了,注释掉数据库 update 操作(记录登录),重启项目,客户端访问提示服务器响应超时。脚本测试模拟登录,也响应极慢。

感觉一时无解,就从台阶站起来,开始收拾东西(下班路上接到的客户电话,Mac 使用 iPhone 无线热点),坐在地铁上码刚刚的经历。

地铁方向坐反,换乘对方向的路上感觉信号很好,就登录客户端尝试,一切正常了,重复登录登出,菜单这种访问,完全正常。

停止码字,再测试继续正常。

反应过来了(内存,Unicorn,阿里云)?

请问 1. 并发测试数与用户人数的大概几何关系

  1. 如何快速应对上述场景(高压恢复到低压后)?(避免这种场景

心得:不要在正式环境做压力测试

What? 1000 个请求就挂了?这也太脆了吧我压测都是几千几万的请求上的。 不过这个磁盘空间1T(挂载)的挂载两字感觉有点慌啊?

惭愧,技术各种菜,不吝指教

说实话这点基本看不出什么。 一般来说有几个点可以看,一个是数据库压力(可以看看进程列表),一个是 Unicorn 进程,一个是磁盘响应速度。 另外还可以看看是不是真的是压测导致的问题而不是偶然的两个事件正好撞在一起了。

#2 楼 @msg7086 虽然日常在 mac/linux 环境中工作,但属于硬件小白,见笑了 #4 楼 @msg7086 受益匪浅,谢谢。 是的磁盘响应速度测试很必要,数据库压力 (远程连接) 如何在服务器命令行中查看?简单查了一下,未果,都是手码脚本。也可能是对阿里云技术的强烈信任,从没往数据库压力方面想过。

下午的压力测试针对的 api,etag 值取自数据表最近的更新日期(where.order.first), 响应结果为下载文件(send_file), 测试不带 etag, 每次都下载,好像就受硬盘响应速度影响了

可以考虑进 MySQL 的命令行看一眼 show processlist。 挂载磁盘和原生磁盘相比还是有差距。 我在 AWS 上用他家的 EBS SSD 磁盘,感觉慢得不行,根本不像是 SSD 应该有的速度。 (相比之前开的独服上的 SSD 那性能简直天差地别) 另外很多云都有 IOPS 限制,比如 AWS 上有一个 BurstIOPS 给你用,Burst 用完了以后就开始限速读写,慢慢恢复水桶令牌。 你可以看看他们家有没有类似的问题。

#2 楼 @msg7086 你怎么模拟上千万请求的?

#7 楼 @mrpasserby 几千几万还是不难的。几千万就有点过火了。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号