这是一个创建于 1388 天前的主题，其中的信息可能已经有所发展或是发生改变。
腾讯云的活动小鸡，性能估计很一般很一般
php 和 sql 都在一机
已开 opcache(感觉不是，没什么提升）
返回大概 10000 多条数据(温湿度传感器)，php 处理成 json 给网页
查询就一个全表返回（已做插入 db trigger 数据分类），没 where 条件，就一个 join 做 id->名称转换(不知是不是瓶颈，是的话丢给 insert trigger)
php 等待约 100ms ，感觉已经爆炸……六张图 10 秒一刷的话估计会把机器卡成鬼
不知道什么地方的问题。
有人讲讲像我这样几千条数据的 SQL 的平均返回时间么，我也有个底……
php 和 sql 都在一机
已开 opcache(感觉不是，没什么提升）
返回大概 10000 多条数据(温湿度传感器)，php 处理成 json 给网页
查询就一个全表返回（已做插入 db trigger 数据分类），没 where 条件，就一个 join 做 id->名称转换(不知是不是瓶颈，是的话丢给 insert trigger)
php 等待约 100ms ，感觉已经爆炸……六张图 10 秒一刷的话估计会把机器卡成鬼
不知道什么地方的问题。
有人讲讲像我这样几千条数据的 SQL 的平均返回时间么，我也有个底……
第 1 条附言 2022 年 5 月 28 日
试了下
把表(Structure and data)dump 下来本机开了个 mysql select *了一下...0.011s...只要 11ms...
是小鸡系统盘 io 太烂的原因么？还是别的什么原因
本机 nvme......
把表(Structure and data)dump 下来本机开了个 mysql select *了一下...0.011s...只要 11ms...
是小鸡系统盘 io 太烂的原因么？还是别的什么原因
本机 nvme......
第 2 条附言 2022 年 5 月 28 日
感谢回复……
怕是 IO 问题，把临时表的 storage engine 改成了 MEMORY......
试了下，还是 100 多 ms...但是估计不是 IO 的问题了.
是普遍存在的 cpu 超售问题么（也不算完全超售，因为很便宜且说明了不支持指定 cpu 型号，难道是老机器？)
怕是 IO 问题，把临时表的 storage engine 改成了 MEMORY......
试了下，还是 100 多 ms...但是估计不是 IO 的问题了.
是普遍存在的 cpu 超售问题么（也不算完全超售，因为很便宜且说明了不支持指定 cpu 型号，难道是老机器？)
 | 1 eason1874 2022 年 5 月 28 日  1 我估计至少有 30ms 用在了 PHP 处理，json_encode 挺花时间的。如果你在 json_encode 之前还逐条循环处理，那就更花时间 你每一步都打印已用 ms 时间数，就知道哪一步用的时间多了 |
 | 2 yankebupt OP @eason1874 可能还真是 php... 我 ssh 上去本机 select *了一下，mariadb 自己报 0.017s...... |
 | 3 Building 2022 年 5 月 28 日 1 直接查出来一百万条一般不会超过 100ms ，时间在 json parse 上 |
| 4 eason1874 2022 年 5 月 28 日 @yankebupt 优化下代码吧。我记得手动拼接 json 字符串比用 json_encode 省时间，好多内置格式化函数用起来方便但会花不少时间，比如 sprintf 。避免用正则，循环也少用 |
| 5 yankebupt OP 多谢.... 看了一下小鸡 ping 8-16ms ，http 备案防火墙估计要吃几 ms…… 去掉了 join 查询 id>name ，放到了 trigger ，省下几十 ms. fetch_assoc 可以改成 fetch_all(MYSQLI_ASSOC)但是不知道有没有提升可能没有 准备手拼 json 了 |
| 6 yankebupt OP 另外的测试结果 返回 10000 多条，如果是直接 query ，就算直接从 MEMORY 表 select *，也要 20ms. 如果是 query 过, cache 返回的话就可以 2-3ms 直接返回 面临如下抉择：是否每次插入时 query 一下存进 cache 最大化加速 php 的返回时间…… 插入平均每秒到每几秒一次(传感器读数) php 平均 5-10 秒一次 但是如果 write lock 把表锁住了就得不偿失了 不知要不要做. 准备自己测试下 |
Select Language