@ahu 就是数据库索引还有队列优化和 redIs 缓存优化，把更多的资源请求和回源放到了 oss 和 redis

@ferock 问题解决了就好了，老哥，莫生气

@Felldeadbird 附言说了啊

@awanganddong 忘记说了，我们是做了 redis 的

@Ansen user sys

@leo108
@gy123
一会程序低频使用的时候，我们打开 PHP-FPM 慢日志低压测看一下

@liuyibao 这些都有考虑到

@heyjei 没有往 Nginx 想，感谢，这个值得排查一些

@lp7631010 对，前端资源都放在了 OSS ，没有用 CDN

@gy123 带宽 100M 的流量计费模式，高压测的情况下，带宽 50%也用不了

@lp7631010 不是

@IDAEngine
@abigeater
瓶颈在接口请求，分析日志看到的是采集点调用的接口请求数量过高，递归把自己写死了，这个问题已经解决了，但压测的情况下，程序打开过于缓慢，这个问题不知道怎么解决

@815979670
@zhs227
@holystrike
这个是历史遗留问题，一开始这个程序是单点预约检测的使用的业务逻辑，后来临时赶鸭子上架，改成了全民核酸的平台，没来得及

12 本两年半了

可能会尝试去国企养老吧，从乙方到甲方，也不用自己码代码，小日子清闲一点，没啥事去钓钓鱼啥的，也挺好！

@seakingii 不是我想省钱，服务器在甲方手里，甲方抠，一直压着我们想解决方法，你这个方法我们是最早提出的方案，图片我们用 redis 做的缓存，被甲方否了。

@Osk [早就想这么干了] ，不行啊，还是得坚守

@seakingii 不是的，是文档数量多，转成图片后图片数量也就非常多了，这样的话，存储也得增加，前端一直在调用图片也会对流畅度造成困扰

@Coolxiaobai 直接转 PDF 会将 PPT 中的课件样式错乱