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

一、概述

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

二、服务器进程内存优化

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腾讯移动游戏技术评审标准与实践案例》

原文发布于微信公众号 - 高性能服务器开发(easyserverdev)

原文发表时间:2018-11-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合基础篇(五)讲一下maven

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载。 前言 项目展示地址,点这里...

2856
来自专栏云计算

微服务的模式 - 同步与异步

微服务是一种架构范例。在这种架构中,多个小型独立组件协同工作,从而构成一个系统。尽管它的操作复杂性较高,但这种范式已经被迅速采用。这是因为它有助于...

1.3K4
来自专栏Java编程技术

分布式事务- 三阶段协议

前面我们介绍了为解决分布式事务而提出来的的二阶段协议,本文首先来讲解二阶段的不足,然后阐述三阶段协议,三阶段协议也是一个标准的协议,也并没有说具体如何实现。

712
来自专栏Python研发

用pycharm提交代码,冲突之后文件丢失找回方法

1: 更新代码时, 监测到本地代码改变,需要和合并,重启之后才可以, 选择No同时,代码会被冲掉,新增加的文件也会被冲掉, 但是pycharm有一个文件历史记忆...

744
来自专栏Spark学习技巧

HBase高可用集群运维实践

随着越来越多的业务选择HBase作为存储引擎,对HBase的可用性要求也越来越高,对于HBase的运维也提出了新的挑战。目前运维集群超过30+,而且接入的业务类...

4255
来自专栏匠心独运的博客

过来人的经验,谈谈一致性处理方案—分布式事务(DTS)

传统事务是使用数据库自身的事务属性(ACID),而数据库自身的事务属性是局限于当前实例,不能实现跨库。而对于大型分布式/微服务集群系统中,不仅存在着跨库的事务,...

3464
来自专栏aCloudDeveloper

vhost:一种 virtio 高性能的后端驱动实现

什么是 vhost vhost 是 virtio 的一种后端实现方案,在 virtio 简介中,我们已经提到 virtio 是一种半虚拟化的实现方案,需要虚拟机...

8286
来自专栏小巫技术博客

App更新策略课程完结篇

1113
来自专栏CSDN技术头条

携程开源Redis多数据中心解决方案XPipe

Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒10W,很多业务甚至会将Redis当成...

4389
来自专栏

基于JMS的数据交换既数据互操作平台的解决方案

为解决应用系统间数据和信息的互通、互用,建立一个通用的、分布式的数据集成平台,用以解决异构数据平台数据交流和沟通的问题。

5044

扫码关注云+社区

领取腾讯云代金券