前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >《天天爱消除》服务器性能优化

《天天爱消除》服务器性能优化

作者头像
范蠡
发布2018-12-17 11:57:13
9750
发布2018-12-17 11:57:13
举报

一、概述

《天天爱消除》服务器已经在外网稳定运行四年多了,日积月累服务器方面出现了一些问题。主要包括内存,强校验性能,异步开发效率,登录等问题。本文记录这些问题的解决方案和优化效果。

二、服务器进程内存优化

2.1 服务器进程内存现状

《天天爱消除》外网机器负载表现为内存占用率较高,CPU 使用率较低,同时因为是弱交互的手游,网卡流量并不会存在瓶颈。玩家同时在线高峰期,机器内存使用出现告警。核心进程组gamesvr 和checksvr 占用内存过多,下图1 是机器内存使用情况。

分析发现checksvr 进程内存主要消耗在加载关卡资源,在一个set 集中,同时

启动了4 个checksvr 进程,每个进程都加载了所有版本对应的关卡资源。

gamesvr 内存使用量正相关于玩家同时在线人数,主要消耗在排行榜。爱消除

排行榜是直接实现在gamesvr 中,并在进程内部缓存。图2 和图3 是checksvr

和gamesvr 内存使用占比示意图。

2.2 服务器进程优化方案

针对checksvr 关卡资源冗余带来的内存开销,新方案中结算校验时通过

gamesvr 在请求包中把关卡资源带过来,从而减少checksvr 常驻内存使用量。

为此会带来一点额外的CPU 拷贝开销。

针对gamesvr 排行榜内存消耗,有两种解决方案。第一种就是把排行榜独立出

gamesvr,形成单独的排行榜服务。但这相当于把内存转嫁到其他机器上面去,

因为新排行榜服务需要申请新机器。另外独立排行榜方案需要对gamesvr 逻辑

代码大量修改。第二种方案是采用CPU 换内存的方式。我们前文提到,核心进

程组机器CPU 使用率比较低。所以最终我们采用压缩排行榜数据的方式优化掉

gamesvr 内存。图4 和图5 是核心进程组内存优化效果。从两图中可以看出我们用不到10%的CPU 增长节省了2.4GB 左右的内存。

三、checksvr 架构和性能优化

3.1 checksvr 功能概述

checksvr 是爱消除后台用来进行强校验的服务。该服务对玩家每次结算请求,

服务器后台运行跟客户端一样的消除库,得出结果,跟客户端上报结果进行对比,从而判断玩家是否作弊。该服务在保证游戏公平性方面有着重要作用。

客户端每个版本对应一个滑动库so,单个checksvr 进程加载所有版本对应的校

验so。图6 是优化前gamesvr 和checksvr 通信示意图。

3.2 checksvr 存在问题

目前checksvr 架构主要存在如下几个问题:

  • 编译耗时。每次客户端发布新版本,后台需要把所有客户端版本对应的so 全部编译。
  • 维护困难。因为后台和客户端共用滑动逻辑库代码,后台每次需要重新编译所有so,客户端在开发新版本时,滑动库相关代码只能增加不能删除,否则会导致低版本校验so 编译不过。
  • 性能问题。tbus 轮询收包方式导致校验请求包在队列延迟大,同时单局较验耗时较长。

3.3 checksvr 架构和性能优化方案和效果

针对3.2 小结提到的问题,我们采用如下优化方法:

1.单进程加载单个版本较验so,可以解决每次客户端开发新版本,低版本校验

so 需要全部重新编译的问题,但是这样会导致checksvr 进程数量变多。

2.根据外网玩家在各个版本的分布情况,合并多版本较验so 到单进程,减少进

程数。

3.在tbus 组件基础上,引入事件通知机制,减少校验包在队列延时。

4.精简滑动库在服务器端的逻辑,perf 工具分析热点函数,提高较验单局性能。

经过上述优化之后,客户端在开发新版本时不再需要重新编译所有低版本so,

同时性能也得到了提升,图8 和图9 是优化前后的对比示意图。优化后队列延

时平均从10ms 降低到了4ms, 单局校验平均耗时从45ms 降到了30ms。

3.4 http 类服务开发效率优化

《天天爱消除》后台存在一些这样的服务,它们通过http 协议与外部平台通信

完成某些交互。比如friendsvr 跟微信、手Q 开放平台通信,完成玩家好友关系

链的操作;dealsvr 跟数平通信,完成游戏一级货币钻石的各种操作。这类服务

基于tapp 框架,采用curl 异步编程模式来并发,它们普遍存在代码维护困难,

开发效率不高等问题。

为解决上述问题,我们在这类服务中引入协程库。对代码进行改造,我们选用公司内部开源协程库libmt。图10 是在tapp 框架中引入协程之后的调度机制示

意图。

引入协程后,这类服务代码开发和维护就像写同步代码一样,结束了异步代码满天飞的局面。图11 是优化前后两种模式下完成一个需求的开发对比图。该需求就是简单统计下,玩家在登录和非登录阶段去数平拉取钻石成功和失败量。

3.5 登录过程优化

《天天爱消除》后台已经在外网运行四年多了,游戏业务逻辑不断增加使得游戏在登录过程中需要下发给客户端的包越来越来多。有部分玩家投诉游戏登录不上,客户端表现认为是后台超时。

外网统计数据表明登录过程中后台下发包量平均在260 个,并且玩家过关数越

多,包量越多。针对登录过程中下发包过多的问题,有两个方案可以考虑,其一是启用Tconnd 的压缩和合包功能,但爱消除的Tconnd 运行在TDR 模式,而

Tconnd 只有在GCP 模式下面才支持压缩和合包。GCP 模式需要客户端引入新

API,这明显不适用于爱消除的情况,因为我们需要兼容版本众多的老客户端。

其二是游戏gamesvr 自己修改逻辑,针对其中影响比较大的协议按照如下方式

分别进行修改:

优化过后外网登录下发包量减少效果比较明显,如下图14 所示。在我们使用的

方案中,新版本客户端基本不需要修改逻辑代码,同时可以通过修改后台服务器逻辑代码做到兼容低版本客户端。

文章作者:腾讯互娱高级工程师-罗雄威文章 来源:《2018腾讯移动游戏技术评审标准与实践案例》

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-11-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 高性能服务器开发 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档