摘要：
为了验证高并发下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在并发上有天生的优势，但各位先辈们的作品中，似乎还没有人数如此高的在线游戏，接下来就一步步的往这个目标进行努力。 阅读全文