最近我在写一份「从grape+puma升级到actix的性能提升」的报告，主要通过ab工具测试，
测试方法是：测试一个GET请求接口，接口的功能是读取数据库一条记录并以json格式返回
测量单位：Requests per second(每秒种能处理完的请求数)，以下简称分
符号声明：本文中将(请求总数, 并发数)的格式简写为(x, y)
Tip
必须要在服务器的localhost环境测，去除网络连接的影响
如果是在本地的mac电脑上用ab测阿里云上的Ubuntu服务器，由于网络连接存在不确定性，对测试结果造成极大干扰
Tip
Concurrency [Range 0..20000]，最大并发数20000
[!DANGER] 注意
Document Length，如果后端报错Response长度会不一样
解决办法：提前用postman/curl测好返回内容的长度，如ab返回的长度不一致则测试结果不可信
案例分享：有一次的测试结果grape跑了2000分，结果查看log后发现ruby报错了没查数据库所以变快了
正常情况下grape+puma需要1ms以上才能完成一个查数据库的请求(ActiveRecord光查一条数据库大约就0.3ms)，跑到1000分几乎不可能
[!DANGER] 如果结果出现失败请求(后端异常)或请求到一半被截断，则测试结果不可信
请求到一半就截断终止了，我没找到原因。
请求出现失败的话，一部分是后端异常，一部分是请求超时，说明已超过框架性能极限，测试数据不可信了。
Note
如果后端性能不好，请求数和并发数不要相差过大
原理：ab的请求数应该是基于一个队列模型实现的，如果前面的请求处理得太慢了，后面的请求可能会TIMEOUT
案例分享：grape在(10000, 1000)的测试条件下会直接卡死...
以下测试结果都是跑三次后取中位数，以消除误差
请求数与并发数一样时
grape(100, 100): 635
actix(100, 100): 2844
grape(1000, 1000): 701
actix(1000, 1000): 2809
grape(5000, 5000): 634
actix(5000, 5000): 2620
并发数到10000时，grape完成9000个请求后会卡很久
grape(10000, 10000): 276
actix(10000, 10000): 2570
grape(20000, 20000): 卡死 actix(20000, 20000): 1443
ab命令最大20000并发，20000并发下我试着将actix的log输出关掉
因为actix日志拦截器会阻塞请求，按以前的经验关掉log能提升10-17%的性能
但是ab的测试结果还是1400左右，证明了(20000, 20000)的测试条件下ab的测试结果不准
测试的意义不大，actix性能基本是grape好几倍，而且grape在高并发下经常卡死，所以grape重构为actix是没问题的