测试的项目基于 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. 如何快速应对上述场景（高压恢复到低压后）？（避免这种场景）