mteamwhy / mt-web-pre

27 stars 0 forks source link

关于页面加载速度的反馈 #225

Closed sirlaurie closed 5 months ago

sirlaurie commented 5 months ago

问题起源于在群里的一个疑问 为什么首页置顶种子的活动数都显示为0, 一位管理员回了个链接 . 看完链接里管理员关于速度的解释, 我查看了一下首页的加载情况, 发现几个问题, 在此抛砖引玉.

以下分析都是基于我位于中国大陆区域并且使用代理服务器的状态下进行的, 部分情况可能随着地理位置不同而有所变化. 我的代理服务器速度尚可, 流畅播放YouTube 4K视频.

下图是 https://kp.m-team.cc/browse 页面第一个脚本文件的耗时情况, (事实上, 前四个脚本文件和样式文件耗时情况也都类似)

screenshot 2

从Blocked和Waitting的耗时可以猜测服务器在处理请求上有瓶颈, 并发性能不够. 不知道具体是由于服务器硬件还是web服务器没有优化好. 理论上来说, openresty处理日3万的访问请求是绰绰有余的.

下图是xhr请求 https://kp.m-team.cc/api/torrent/search , 也就是综合页面的内容请求耗时情况

image

可以看到浏览器等了11秒, 这也是进入综合标签页面耗时最长的原因, 从返回的结果看, 服务器似乎使用了select * from torrent limit 100简单粗暴的方法查询MySQL, 结果中有很多前端没有展示出来的字段信息, 这些都是不必要的查询. 建议可以只查询前端需要的字段, 变且把limit调整的小一点, 比如20, 因为进入这个页面后, 20个种子信息足够访客查看了. 同时监测页面滚动, 如果有滚动事件, 再加载剩余的种子.

其他几个xhr请求也有类似的问题, 比如制作组列表, 页面初始化的时候可以不用加载, 等到用户点击高级搜索后再进行加载, 可以节省时间, 也能分散服务器处理能力. 同时从前端来看, 制作组的字段信息只需要 id, order, name三个字段就够了. 这样可以节省查询数据库的时间.

mteamwhy commented 5 months ago

先回limit的問題,一開始就是20個,後來是眾多會員要求才改到100個,所以後續優化還在研究怎麼做

mteamwhy commented 5 months ago

整個問題還是在訪問cf的速度,建議觀看https://wiki.m-team.cc/cf-choose-better-ip