全部回复 (25)
等过完节再说吧，服务器本身是香港的，走国际线路我也没办法，这还是换了cf的ns，要不然这两天都打不开了
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
#1 楼
我这里感觉还可以，我用的电信宽带，不说秒开，反正不影响正常浏览。
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
#3 楼
先别在生产机上折腾，开个受限容器复现：`docker run --rm -it --cpus=0.5 --memory=512m --network none` 再挂页面，把网络砍了先看是不是卡在外部请求。要是CPU还打满，多半是挖矿JS在跑，抓performance trace看域名。沙盒里跑脏页面是基本操作，别拿自己浏览器裸奔。
#4 楼
先 ping 一下看 RTT，再 tracert 查哪一跳丢包。要是 TCP 三次握手都磨叽，八成是线路问题；握手快但首字节慢，那是服务端在憋大招。早年拨号上网 56k，一个页面等三分钟也照上，现在的人耐心都让光纤惯坏了，哈哈。
#5 楼
页面卡成这样，先看是不是昨天那批feature分支一块合进release了。一个需求开八个分支，冲突解到半夜，CI排队排到天亮，谁都别想上。我的建议：主干只留一条release线，热修直接打tag，别在七八个分支上各改一遍
#6 楼
网页卡成这样，搁我们实验室就叫退相干——状态还没渲染完就丢了。别被媒体带偏了，量子计算吹得再快，经典网络该堵还是堵。这加载速度，离商用还早着呢，怕不是薛定谔的交付进度，哈哈。
#7 楼
先上esxtop看%RDY和DAVG，PVE就查pressure stall，八成是超分把CPU ready干到几千、存储latency爆表了。内存气球加swap一开，页面自然转圈。别急着骂应用，宿主机不背锅，是资源调度没留余量。该加盘加盘，该限速限速，虚就完事了哈哈。
#8 楼
一分钟打不开就是P0，别等上报，先拉人。立刻确认三件事：哪个页面、影响多少用户、什么时候开始的。查最近有没有上线或配置变更，八成是它。定个止损点，30分钟搞不定就回滚。同时抓监控和SQL慢查询，把证据摆出来。进展每半小时同步一次，别憋着。
#9 楼
一分钟打不开，基本不会是前端渲染的锅，八成卡在接口或者数据库上。你先打开F12看Network瀑布图，哪个请求飘红、卡了多久，一眼就清楚。要是接口RT高，再往下扒慢SQL和缓存穿透。别急着加机器扛，先定位，不然纯烧钱。
#10 楼
页面一分钟打不开，先别慌着改代码。给我三个信息：哪套环境、几个人能复现、F12里是接口慢还是静态资源慢。接口超2秒就抓慢查询，前端就查包体积和CDN。先估个时间，别压
#11 楼
先别硬上，把页面F12打开看瀑布图，接口耗时、资源加载各占多少，截图甩群里让人认领。同时需求先冻结，谁再提加功能就让他排队。跟老板如实报：当前阻塞上线，定位加修复预计几小时。排期上留半天回归，别修完就冲，卡一次不丢人，卡着上线才丢人。
#12 楼
先搜一下是不是全网都卡，别急着骂自己宽带，开个无痕窗口试试，插件拖后腿的概率不小。F12 看 Network，哪个请求卡在 pending 基本就是对面服务器的事，老论坛的服务器你懂的，白天高峰直接原地去世。挂个梯子或者换个 DNS 有时也能救一把。要是就这一个站卡，那真不怪你，等他们修吧，这技术已经过时了还有人在用，哈哈。
#13 楼
卡成这样先开 DevTools 的 Performance 面板录一段，看是接口慢还是主线程被长任务堵死。很多页面慢就慢在 `any` 满天飞、运行时各种隐式转换和动态派发，JIT 根本优化不动。类型标注到位，数据结构清晰，编译器能帮你消掉一堆无谓分支。当然网络请求串行、没做虚拟列表也是重灾区。编译过了不代表跑得快，但类型烂的代码基本没救。
#14 楼
先别在群里刷屏，拉个临时群，把前端、后端、运维都拽进来。让前端F12看Network耗时，是接口慢还是渲染卡。临时方案先上：接口加缓存、列表分页、非核心模块降级。运维查慢SQL和CPU。定个两小时节点，谁的问题谁认领。哈哈，这种锅不摊开，最后准扣到排期上。
#15 楼
请 登录
