从你提供的 wrk 测试结果来看,这是一次针对本地服务器地址 http://127.0.0.1:19878/test 的压力测试。下面是对测试结果的解读:
测试持续时间:-d60 参数指定了测试持续时间为 60 秒。
线程和连接:-t12 表示使用了 12 个线程,-c100 表示每个线程有 100 个并发连接,总共 1200 个并发连接。
线程统计:
平均延迟 (Latency):请求的平均响应时间是 2.40 毫秒,这表示服务器处理请求并返回响应的速度相当快。
标准偏差 (Stdev):延迟的标准偏差是 1.83 毫秒,这表明大部分请求的响应时间接近平均值,但也有少数请求响应时间较长。
最大延迟 (Max):最长的延迟是 54.80 毫秒,这是在测试期间记录的最长响应时间。
百分位 (+/- Stdev):83.78% 的请求响应时间在平均值加减一个标准偏差的范围内。
请求统计:
每秒请求数 (Req/Sec):平均每秒处理的请求数是 3.65k(即 3650 个请求)。
每秒请求数的标准偏差:请求数的标准偏差是 1.21k。
每秒请求数的最大值:在测试期间,每秒最多处理了 6.92k 个请求。
请求数的分布:63.15% 的请求在平均值加减一个标准偏差的范围内。
总体统计:
总请求数:在 1 分钟内共发送了 2613801 个请求。
总数据量:读取了 752.82MB 的数据。
每秒平均请求数:Requests/sec: 43537.19 表示平均每秒处理了 43537.19 个请求。
每秒平均数据传输量:Transfer/sec: 12.54MB 表示平均每秒传输了 12.54MB 的数据。
这些结果可以帮助你了解服务器在高并发情况下的性能表现。如果需要进一步优化服务器性能,可以根据这些数据来分析可能的瓶颈和改进点。
我这边php什么优化都没有开启,完全是白板环境;缓存什么都没有上。
原文:
正确的理解应该是:
MySQL 就是这个性能,这是正常飙高。
如果换成pg呢,会不会好很多啊
会差很多,pg读取性能在众多数据库中属于最弱的那一档。
佬,给一个意见缓解下压力呢?
首先,MySQL 4万/秒的读消耗400-600%的CPU是正常的现象,换其它关系型数据库也差不多少。
而你正常业务QPS可能就几个,与4万相比如九牛一毛,也就是说正式环境CPU消耗基本可以看作为0。
你是没试过tp或者laravel,2000QPS就能把CPU干满。而webman能达到4万已经是逆天的成绩了。
不要浪费时间在webman框架或数据库选型上,有那时间不如写好SQL,做好索引,优化业务减少SQL调用来的实在。
我如果优化环境,结果还能往上彪,代码以及是最简介了。
都是高手
我菜鸟,我想再追问一下,举通俗的例子来说:也就是说这个 4 万,我是否可以粗略理解为 4 万个用户,同时用过 webman 来访问数据库,是没什么太大问题的?前提是 SQL 写的不错,索引也有。
只能说题主测试的业务可以支持4万用户同时访问。
但正常业务不会只有一个SQL,正常业务QPS不会这么高。
还有正常业务也不会有这么大访问量,能超过100就不错了,你们都考虑上万QPS是认真的嘛?
我们有一个小程序在同一个时间,可能会有 1000-2000 人,同时使用,使用持续的时间在 1 分钟内, 1 分钟后就没有人用了,所以想了解 webman 的压力测试。
扛得住,优化sql语句。多层缓存架构。随便抗。SQL优化很好,还是有点压力建议走云数据库主从,内网互联。
我目前的架构是,redis + mysql 的方式,表能建索引的都建了。我们目前是一台服务器,服务器里有 nginx + mysql ,如果后期建议走云数据库(我们没用过),是不是指的是云数据库挑选比云服务器硬件配置高的就 OK ?
云数据库比你们在服务搭建数据性能更强的。毕竟是专业数据库。而且你们突然某一个时间数据库抗不住,也可以临时加钱上扩容。
好的,懂了。谢谢古人重来~