出处 http://blog.csdn.net/mu_gong/archive/2005/02/19/293246.aspx 节录其中几段.. 第一次尝试这种类型的Mud，并没有想到会如此受欢迎。在不到一年的时间， 甚至许多功能都尚未完成的时候，不停的有新人加入这个游戏空间。原来是 不希望设上限人数的，我们希望 :「想玩就可以来玩。」。但是人数一再增 加，整个系统慢了下来，於是我们不停的尝试各种方法来提高人数上限，包 括改写Mud library、更换硬体、更新MudOS版本、修改linux kernel以突破 file descriptor上限256的限制等等。 圣殿以前人数常卡在 24x(不含 logon) 的原因应该是最後一个，其它该做 的大概都做了，大抵上人数不断提高时，会遇到的问题以及初步会采取的做 法都大同小异。 改写 mud library: Int、Satin 时期改写过一次，nobu、myst 时期听说又 改写一次，nobu、laechan 时期则以最佳化为主。 更换硬体: 其实可以换成双核心的 machine，nobu 的意思是双核心对跑mud 在效能上助益不大，目前的主机是 P4。 更新 MudOS 版本: 目前的版本算蛮新的，将来考虑换成某一版可支援多port 登入的(啊，目前的不晓得可不可以..) Mud OS可以看成是一个virtual machine，执行专属的中间码。在virtual machine是single thread的，也就是说一次一定会把一个指令或物件里的 一个method执行完毕，才轮到下一个。 Mud 需要处理以下三件事情 : 1. 每隔固定的间隔时间必须执行的 : 比如说每个生物的心跳。 2. call_out queue : 有些指令在执行的时候为了要造成延迟的效果， 会以call_out函数指定过了几秒後要跳到哪个函数执行，有点像 sleep()。Mud OS会将call_out发出的请求依时间挂在一个queue, 每隔一阵子就去检查是否到了执行的时间。 3. 使用者下的指令。 为啥要尽量减少 call_out 的使用, 上面有大致的说明. 但实际上目前大 量以其它方式替代 call_out 也会产生问题就是了. 目前的 mudos 不晓得有没有非 single thread 的处理方式. 整个过程大概可以写成 : While (1) { process_heart_beat(); // 心跳，每两秒一次 process_call_out(); // call out queue process_user_command(); // user command } response time = 网路传输时间(来回) + 执行指令的时间 而 执行指令的时间 = f ( 硬体的速度，virtual machine的效能， 指令本身的复杂度，物件数目，使用者数目) 其中物件的数目受直接受使用者数目的影响，而小心设计可以降低指令的复杂度。 一般情况下 loading 是平稳的, 而人数越多, 经过 process_heart_beat() 时要处理的量就越大. 其它是能省则省了, 像圣殿这样在战斗中要狂按一些指令的情况其实是可以 再更省一点. 另外指令的最佳化也是未来的重点, 特别是常用指令如 heart、go、特攻指 令等. 如何提高人数上限 1. 提升硬体设备 : a. 使用更快速的CPU b. 使用高速记忆体与硬碟 这是最简单的方法了，然而硬体升级的速度比不上进入网路世界的人口成长 ，而且如果每次人数饱和就更新机器，将需要一笔可观的费用。 以目前来说，P4 3.2G / 4G DDR2 800 / SCSI HDD，跑 mud 应该很呛了,上 述花费大概 20000 以内就搞定, 在 onyx 写上面文章的时代则是无法想像的 (如果拿 DDR3 的 ram 来插应该会更呛) 像以圣殿目前主机的等级来看, 跑 3xx 人其实已经不太困难. 2. 加强virtual machine的效能，小心设计library ‥ 现在TAnet上的Mud多半是拿国外的virtual machine(Mud OS, driver) 来使用，使用新版本的virtual machine可以大幅提高执行速度。 ‥ 小心设计library，尽量不要设计的太复杂，将最花时间的一些动作与 指令最佳化。 ‥ 最佳化library能够收到的效果有限，往往最多只能增加10~20个使用者。 最佳化的效果其实是很高的, 它的好处就在於更新机器时效果会更显着, 以及当某一部份的系统档案出问题时, 整个 mud 即使速度整体被拖慢, 也还能再撑一段时间(例如之前圣殿出现的大 lag 情况, lag 成那样了, 还可以不 crash 继续撑) 而且最佳化的过程也可以学习怎麽写程式来尽量减轻系统的负担. onyx 之後的文章就提到了如何架构分散式系统, 简单的说就是当一部 pentium 200 的主机最多只能跑 250 个玩家, 而 kk 想跑 1000 个玩 家同时在线时, 依 onyx 及 ruby 的说法就是, 只要把四部 pentium 主机「串接」在一起就行了。 (这种想法据说是 onyx 论文的基础) 但科技真的是日新月异的, 而 mud 则逐渐凋零, 两条线约在 kk 人数 还有 5xx 的时候交叉, 而以现况来说, kk 经常在线人数 3xx~4xx，一 般家用主机则已经进步到四核心时代... 目前的圣殿不需要搞分散式架构大概可以跑 400 人(我的预估)，超过 时有几个备用方案.. 一、把 user.c 的 heart_beat 最简化 二、把常用指令最简化 三、取消一些常用指令的周期性使用方式，改成上线後使用一次即可 四、减少 1 ip 可 login 的角色数 Laechan --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.65.137.33