-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于覆盖率 #65
Comments
到这个地步了的话... 就该整理代码了 |
白天覆盖率稳了,有统计晚高峰的吗?我看了下这两天的还是和之前一样,白天几乎没漏的,一到晚高峰就不如非解限版,会漏大概1/3,CPU负载也不是太高,流量26 27个GB,非解限版流量16GB左右。 |
1/3会是风暴吗?风暴id的前半截是跟舰长一起的23333 |
刚算了下 |
不是风暴,我是和非解限版对比。可能还是网络问题,连接数多对网络质量要求高,用国内机器应该好些,可惜国内我只有1M带宽的,不知道能不能跑起来。 |
嗯... 有什么建议吗 任何策略都行,我看下实现的可行性 |
你那里正常的话,我觉得可能是linux系统优化的关系,tcp连接数超过某个阈值就出问题了,用的都是全新安装的debian10默认的参数,我先优化了一下参数跑两天试试。 |
用的是Linux分支的版本吗 |
有root权限的话可以系统层面上提升弄nofile上限(限制tcp句柄数量的好像是) |
是的,ulimit和file-max一开始就改过了,tcp超时和回收啥的参数没弄过。 |
毫无头绪2333 |
我直接在一台vps上同时开17号的版本和最新版,这下全都一样了。 |
162/200漏的太多了啊.... 我专门写个限制版给你吧~ |
大佬就按自己思路弄就好了,不用专门写啊。而且你那边测试正常,其实高峰期解限版也就1W多连接数,和五六千连接数的限制版不应该出现这种差别才对。我觉得可能不是连接数的关系,我再找找原因。 |
嗯 我期待好消息 |
下午到晚上8点半之前,限制版会漏几个,解限版几乎没漏,8点半之后解限版就开始漏了。 |
原来是这样... 那我可以安心肝覆盖率了hhh |
不过我还是挺好奇为啥限制版受到网络影响就比较小,是掉线重连的逻辑不一样吗 |
断线重连的策略没变 |
我服务器刚刚被412风控了23333 |
嗯… 刚刚跑的是测试版 error掉了好几次 |
果然是大佬23333 ip获取这些我不太会呢~ |
看来要手动getaddr吗... 然后采用均衡负载吧 |
netstat -plan|grep :2243|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1 |
借一下你们的command23333 |
对了 Clone新的版本的时候别忘了把旧的 |
猜测DNS解析是由b站反向代理均衡分配的 |
解决了,这回应该救得不能再救了,总感觉自己智商不够用,盯着个数组看了半天才想明白。 |
大佬太肝了吧 不早点睡吗 |
没错... 有次测试触发了风控 翻车现场十分惨烈 |
其实,就是盯着数组看了一个小时才想清楚怎么让网络好的IP平均分配连接,找了台网络好的试了下,掉线率都很低的是平均分配IP了,网络差的也比较正常,不过那个统计掉线策略还是不太好。风控不知道是不是因为短时间内对同一个IP大量连接请求。对了,顺便说下客户端好像断开后不会重连,比如路由器重拨,心跳似乎在运行,但是不抽奖了。 |
不重连的情况我需要多点信息 是完全收不到播报吗? |
路由器重拨试了几次,完全收不到,日志就停留在断网那个时候了,不过直播挂机经验一直在涨。 |
懒得再去那边开issue了,刚单独测试了下。 |
是我疏忽了 测试的时候全程跑服务器的 没考虑过客户端断网的情况 |
先鸽几天 有课了 |
hhh结果又肝上了 |
太强了吧 这么多服务器测 不贵吗.... |
都是各种便宜的辣鸡VPS,专门用来瞎折腾的 |
我以前用的aws和现在跑的学校服务器都挺稳 而且线路都是海外这边的 |
原本以为要解决网络问题很简单,切换网络好的IP就行了,结果一写起来全是坑 |
早点睡 我也没多少时间写代码了反正 |
把房间添加到永久监听的时候,似乎有几率会漏,比如连上两个舰,检测到第一个舰长后从动态转到静态,然后第二个就漏了。 |
快忙死了hhh 不过问题了解了 暂时想不到转静态那几秒的差时怎么处理 |
好吧想到了 |
一写就是几个小时... 结果作业都没动一下 wsl |
静态目前的策略是慢慢收集 我这边有接近5000静态了 如果有更激进的获取方式更好hhh 动态的问题可以放一放 先攻静态吧 |
对了,还有个误区纠正一下,nodejs的setTimeout运行完成几秒后就会完全释放内存,辣鸡chrome吃了内存就不吐出来 |
果然 NodeJS的v8引擎gc还是很不错的hhh |
要不开播的房间舰长数大于50的都直接添加到静态里?还有就是如果长期不播的可以从列表里删掉。 |
舰长数要访问两个API才能弄到 上次我被风控就因为获取舰长数导致的23333 |
这个我想了下 可以在建立连接后用 TypeScript的重写差不多完成一半了 重构了些部分 顺便写进ip也是可以的 |
静态房间你可以用我的那一套就行,我间隔几个月就会跑一次。数据在 1.5w 左右 |
我这个不要紧... 静态有万了 不过一直没放上来2333 |
The text was updated successfully, but these errors were encountered: