[閒聊] kk 的 onyx 寫的文章

看板mud_sanc (Sanctuary - 聖殿)作者laechan (小太保)時間17年前 (2009/01/30 01:38)推噓7(7推 0噓 0→)

留言7則, 4人參與討論串1/1

出處 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