摘要:
在对游戏进行测试时,发现在某台服务器上,经常会出现一个错误,而其他服务器表现正常,于是分析日志文件,发现以下错误:{badarg,[{erlang,is_process_alive,[<6703.38.0>],[]}检查代码后,发现错误发生在如下的情景下:玩家连接tcpserver,tcpserver产生玩家状态机实例,然后在状态机中rpc call大厅服务,大厅服务保存了当时的玩家状态机pid,之后的操作均会用到这个pid。当进行开启了2个tcpserver(即多用户入口)时,由于使用了is_process_alive来确保pid是可用的,导致这个函数直接报错。erlang在节点 阅读全文
摘要:
最近在使用idea进行一些开发,之前都是在ide里写代码,运行均是手动在shell中,在idea里尝试直接运行,实际上相当于在命令行中使用-run 或-s ,却发现有2个问题。1、使用io:format输出时,和shell中的结果不一样。-s:ddd["1"]shell:ddd12、使用递归函数时,报参数匹配错误{badarith,[{tc,a,1,[{file,"f:/qinyuxi/tset1/src/tc.erl"},{line,13}]}写了一个测试程序检查-module(tc).-export([a/1]).a(10)->10;a(A)- 阅读全文
摘要:
为了验证高并发下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型更为适应一些。 阅读全文