Goscon
3 篇项目上线啦
历时 3 年半，项目终于上线啦，打开 tig 翻到仓库的开头，看看提交历史，还是有点感慨的，实在没想到要花这么久。简单聊点线上问题吧 这次上线最刺激的是，开服前半小时，发现昨晚压测的服务器崩掉了，原因是聊天服务内存太大导致 OOM。于是用 memlimit 紧急止血，出问题的方法挂到模块上方便后续线上热更，然后打包，重启，紧赶慢赶在开服前几分钟搞完，提前开服错峰。真的非常非常刺激，当然，线上也没有出现这个问题，我们压测的例子相对比较极端，一大堆人每 30 秒集体跳场景，注册场景聊天的地方又做了锁 …
历时 3 年半，项目终于上线啦，打开 tig 翻到仓库的开头，看看提交历史，还是有点感慨的，实在没想到要花这么久。简单聊点线上问题吧 这次上线最刺激的是，开服前半小时，发现昨晚压测的服务器崩掉了，原因是聊天服务内存太大导致 OOM。于是用 memlimit 紧急止血，出问题的方法挂到模块上方便后续线上热更，然后打包，重启，紧赶慢赶在开服前几分钟搞完，提前开服错峰。真的非常非常刺激，当然，线上也没有出现这个问题，我们压测的例子相对比较极端，一大堆人每 30 秒集体跳场景，注册场景聊天的地方又做了锁 …
流量压缩
最近中间件组开始尝试推送 goscon 流量压缩的更新，继上次用 libev 改写 goscon 提升效率后，又是一大改进了。可惜我们没机会上了，CM 觉得我们没有带宽的压力，引入更新只会增加潜在风险。站在团队角度看，我很能理解这个理由啦，但是单纯的从技术追求角度看，又心痒痒的很想上，纠结 ing 中间件组的实验报告很有意思，中间提到了一点，sproto 的 pack 算法反而会降低最终的压缩率，sproto 的 pack 是针对二进制串里连续的 0 做的压缩，应用层做了压缩后，反而影响到压缩算 …
最近中间件组开始尝试推送 goscon 流量压缩的更新，继上次用 libev 改写 goscon 提升效率后，又是一大改进了。可惜我们没机会上了，CM 觉得我们没有带宽的压力，引入更新只会增加潜在风险。站在团队角度看，我很能理解这个理由啦，但是单纯的从技术追求角度看，又心痒痒的很想上，纠结 ing 中间件组的实验报告很有意思，中间提到了一点，sproto 的 pack 算法反而会降低最终的压缩率，sproto 的 pack 是针对二进制串里连续的 0 做的压缩，应用层做了压缩后，反而影响到压缩算 …
golang编译问题
最近中间件来了一位新同学，帮忙将goscon的重构了，着重提升了goscon的网络读写性能。这个修改通过cgo的方式引入了Linux的epoll，比golang原生的网络读写好多了。但是在QC同学的祖传ubuntu 16.04镜像上，死活编译不通过，网上也没找到资料，所以留一篇记录，方便以后查询 报错信息： /usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 …
最近中间件来了一位新同学，帮忙将goscon的重构了，着重提升了goscon的网络读写性能。这个修改通过cgo的方式引入了Linux的epoll，比golang原生的网络读写好多了。但是在QC同学的祖传ubuntu 16.04镜像上，死活编译不通过，网上也没找到资料，所以留一篇记录，方便以后查询 报错信息： /usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 …