摘要:
为了验证高并发下gen_server的处理性能,写了一个测试程序,如下:1-module(testserver).23-behaviour(gen_server).4-export([start_link/0]).567-export([init/1,handle_call/3,handle_cast/2,handle_info/2,terminate/2,code_change/3]).89-record(state,{users}).10-record(user,{id,pid}).1112start_link()->13gen_server:start_link({local,?M 阅读全文
摘要:
前面分析的几种情况,归纳一下,其实就是一种,一个提供服务的gen_server,自身处理的时间本来在一个很低的范围内,但由于高并发带来的消息队列,造成处理的时间成几何级数增长,goolge了一下,没找到相关的内容,只能自己做一些细节上的努力。1、gen_server中收到消息后,只进行必要的处理,将广播消息放入新进程中处理,虽然增加了整个游戏的进程数,但这也是erlang的推荐方式,但同时,只能用于一些不需要返回给调用者的处理。2、同步改异步,既然同步调用会超时,那么改为异步请求,你处理好了再给我,这种方式缺点很明显,需要修改大量代码,也会把一些顺序逻辑变成触发式的逻辑,就算付出时间修改好了, 阅读全文
摘要:
最新的一个游戏项目,是一个单服游戏,也即整体游戏只有一个服,也代表着它需要一个高在线,高并发的服务端。游戏本身的结构很像一个棋牌类游戏,拥有大厅、房间等概念,也可以看做类似C9一样的房间内战斗的RPG游戏,玩家选择一个频道(大厅)进入,同在一个频道的玩家才能互相看到以及组队,但不同频道的玩家仍然数据是相通的,可以进行查找、聊天等活动,也有一些所有玩家数据都会参与的计算,比如排行榜之类的。由于是单服,游戏的常规在线人数在2万人左右,虽然Erlang在并发上有天生的优势,但各位先辈们的作品中,似乎还没有人数如此高的在线游戏,接下来就一步步的往这个目标进行努力。 阅读全文
摘要:
经过一段时间开发,大部分功能已经完成,开始了性能测试以及调优,遇到一些性能热点:1、主游戏服务由于每个玩家是单独的状态线程,表现良好,但其中的一个玩家数据管理服务(主要提供查找以及广播)出现了调用超时。2、大厅的数据管理服务(主要提供查找以及动态创建、销毁)出现了调用超时。3、数据服务出现了调用超时。以上测试均在开启了5000个玩家机器人,每秒并发200-300时进行。而超时错误一般都是由于处理速度远低于消息队列形成,而增大超时设置(默认是5秒)是极不推荐的做法,应该从根源上进行分析:1、经过性能分析检查,发现在世界聊天广播时消耗的时间过大, 最大值达到了7秒,而正常测试时,给5000人发一个 阅读全文
摘要:
首先在架构设计上,利用Erlang的特点,采用分布式构成,分为4个节点:数据服务、房间、大厅、主逻辑处理。其中:数据服务:提供对数据库的读写操作。房间:通过一个房间管理器,动态的创建、管理房间。大厅:通过一个大厅管理器,动态的创建、管理大厅。逻辑:也即游戏主服务,socket管理,玩家数据管理。数据库选用了mongodb,主要原因是性能比较高,不需要添加缓存层,还有一个是支持接近sql的查询,目前大多数人都是多年使用关系数据库的经验,这样过渡比直接到key/value型更为适应一些。 阅读全文
摘要:
最新的一个游戏项目,是一个单服游戏,也即整体游戏只有一个服,也代表着它需要一个高在线,高并发的服务端。游戏本身的结构很像一个棋牌类游戏,拥有大厅、房间等概念,也可以看做类似C9一样的房间内战斗的RPG游戏,玩家选择一个频道(大厅)进入,同在一个频道的玩家才能互相看到以及组队,但不同频道的玩家仍然数据是相通的,可以进行查找、聊天等活动,也有一些所有玩家数据都会参与的计算,比如排行榜之类的。由于是单服,游戏的常规在线人数在2万人左右,虽然Erlang在并发上有天生的优势,但各位先辈们的作品中,似乎还没有人数如此高的在线游戏,接下来就一步步的往这个目标进行努力。 阅读全文