vtbs.moe
vtbs.moe copied to clipboard
dd-center
解决过多同接/流量/同时在线用户导致网站卡死
解决过多同接/流量/同时在线用户导致网站卡死
从 #354 后的延续，目前爬虫负载过高问题已经基本解决（从200%~300%下降到了80%~120%左右）
但是从5月10日用户激增的情况来看（GA数据显示比前一天多了265.2%），网站在高峰期多次卡顿甚至卡死崩溃，甚至影响到了数据收录，感觉在现有服务器配置下不做些什么，实在是有些扛不住这么多新增流量
（服务器配置: High Fequency, 3vCPU, 8192MB RAM, 256GB NVMe, 4.00TB流量每月）
目前观察是，从340同接后就出现了严重的卡顿，服务器最高突破了400多。
不过经过几次压力测试，本地性能强几倍的电脑也只有880同接，所以代码上可以优化的地方应该也比较多，不然烧了很多钱也只有一倍的提升，随着以后vtbs.moe收录和用户的快速增长，还是没办法实现可持续性。
短期解决方案：
- ~~加大烧钱（已经一个月$50刀啦，现有服务器再升级也只能选择$96刀或$144刀一个月，先饶了Simon吧）~~
-
- [x] 一边压测一边 调优socket.io
-
- [x] 解耦数据采集和展示部分，避免页面卡死导致的数据采集失败，网站过载的时候居然爬虫也蹦了，会产生800%负载并且无任务给分布式DD爬虫
-
- [ ] 去profile一下看看到底哪里性能不行，我正在陪着Simon不断的压测socket.io和本地数据 @H4M5TER可以帮忙看看么
长期想法：
Simon说打算直接上ws，也许考虑去掉socket.io，yuyu说倒是觉得不如直接把全站的ws都关掉，改轮询就能上cdn了，ws你始终要直连source（成本太高） 天津风大概可以帮助重构一下？@bbrabbitt
第1点
加大烧钱（已经一个月$50刀啦，现有服务器再升级也只能选择$96刀或$144刀一个月，先饶了Simon吧）
垂直扩展，以增强服务器服务能力。可是这种方式成本太大，而且局限性明显。对于这种为爱发电的兴趣项目，无疑是雪上加霜。 @simon300000 😂
第2点
一边压测一边 调优socket.io
个人觉得在 At the OS level 章节的两点建议具有理论上的可行性：
- increase the maximum number of open files
- increase maximum number of available local ports
这两点都可以增大网站的并发连接数，但是，应该清晰地认识到，在服务器资源一定的假设前提下，增大连接数会导致响应时间的下降。因此，如果可以的话，应该评估响应时间的min/average/max指标，以免造成服务体验劣化到不可容忍的地步。
其他思路，考虑设置一个并发连接数的阈值限流机制：
- 可以考虑排队系统，当并发连接数达到阈值后，不再允许继续连接，除非有空位让出来。这样显然会让服务体验下降，但是起码比拖垮整个系统好，可以参考游戏登陆的排队机制（为啥要排队，还不是因为承受不住连接压力。在体验降级和整个系统崩溃的抉择下，选哪个是很明显的。）
- 阈值可以是弹性变化的。阈值取决于之前的经验估计，以及服务器资源增加或者减少的变化。
第3点
解耦数据采集和展示部分，避免页面卡死导致的数据采集失败，网站过载的时候居然爬虫也蹦了，会产生800%负载并且无任务给分布式DD爬虫
应该隔离视图层和数据层，看成两个不同的系统（app），避免连锁效应。如果以前代码是耦合的，那就应该考虑重构，尽早分离。~~以前欠下的技术债，迟早是要还的。~~
长期想法
websocket vs socket.io
| 比较方面 | websocket | VS | socket.io |
|---|---|---|---|
| 本质 | protocol | - | library |
| 性能开销 | 轻量 | > | 较大 |
| 易用性 | 低。 | < | 高。封装了logging、autoconnect、room等实用机制。 |
| 兼容性 | 低。（不支持旧浏览器） | < | 高。（封装websocket，HTTP长轮询等。根据目标浏览器可以自动降级和升级。） |
| 网络流量 | 略低。 | > | 高。（涉及到协商，决定是否降级和升级，因此额外开销为协商流量）》> |
初步结论：
- websocket的优势是轻量，网络流量略低。缺点是易用性、兼容性的下降。
- socket.io的优势是易用性和兼容性高。但由于是一个库，因此性能开销较大。而且需要协商协议，因此初始流量略大。
没有真正完美的东西，各有优劣，就和手写代码和使用框架一样，必须有所权衡。 看中websocket的轻量，就得付出更多的代码工作量。
我记得网站之前使用的是socket.io 2.X版本，当初我试了socket.io 4.x版本去连接，直接被拒绝连接。不知道现在升级没有？
参阅：
- https://stackoverflow.com/questions/10112178/differences-between-socket-io-and-websockets
路过，发表下意见。如果不认同，请忽略。
很有参考价值的发言，谢谢回复！尤其是调优这里我正在测试，我按照你的说法试一试看。 还有现在vtbs.moe依然在使用socket.io 2.x的版本，倒是DDatHome的Node版本目前已经在使用ws了。
设想操作流程
目前看来，横向拓展服务器配置和数量似乎是最简单的选择 但是这样会带来一个问题：“💴” 既然提出了这个方法，那就一定会是有办法解决服务器问题的 我们没有办法来快速搞钱（毕竟那些都写在刑法里了） 但是可以在缩减耗费资金的情况下来提高服务器硬件配置及带宽 也就是使用“试用金账户”开通服务器
（而这些账户通常异常的廉价！但是代价就是在试用金用完后，服务器会被立刻关闭）
所以我的建议是：
优化爬虫部署流程，将中心服务器仅作为数据存储服务器 选择非常规方式获得的高配服务器 在试用金耗尽后及时更换下一个账户
200刀试用金账户一个成本也就七十块钱 （一台 4C 16G 200G 5Gbps的服务器200刀勒/mo）
目前已根据用户最后一次开播的分区为筛选条件 通过爬虫从B站7.1亿用户中筛选出来了 约6W个 在 虚拟主播分区开播过的 虚拟主播！
😨那么多啊
目前把爬虫和io分了两个进程，希望可以缓解一部分问题 https://github.com/dd-center/vtbs.moe/commit/876c3f565b6bb58e8a1570f420a7d13fded758dd