原文鏈接：http://codemacro.com/2012/04/25/game-server-info-2/
上一篇談了一些關(guān)鍵技術(shù)的實現(xiàn)方案。本篇描述一些遇到的問題。
一
在策劃制作完了幾個職業(yè)后（主要是技能制作），大概去年年底公司內(nèi)部進(jìn)行了一次混戰(zhàn)測試。30個角色在一個場景進(jìn)行混戰(zhàn)，測試結(jié)果從技術(shù)上來說非常不理想。首先是客戶端和服務(wù)器都巨卡無比。服務(wù)器CPU一直是滿負(fù)載狀態(tài)。而客戶端又頻繁宕機。
我們關(guān)注的主要問題，是服務(wù)器CPU滿負(fù)載問題。最開始，我通過日志初步定位為網(wǎng)絡(luò)模塊問題，因為邏輯線程表現(xiàn)不是那么差。然后考慮到技能過程中的特效、動作都是通過服務(wù)器消息驅(qū)動，并且本身特效和動作就比一般網(wǎng)游復(fù)雜，通過逐一屏蔽這一部分功能，最終確認(rèn)確為網(wǎng)絡(luò)模塊導(dǎo)致。然后團(tuán)隊決定從兩方面努力：重寫網(wǎng)絡(luò)模塊，改善性能；改善技能實現(xiàn)機制，將表現(xiàn)類邏輯移到客戶端。
至于網(wǎng)絡(luò)模塊，在后來才發(fā)現(xiàn)，雖然網(wǎng)絡(luò)流量過高，但導(dǎo)致網(wǎng)絡(luò)線程CPU滿的原因竟然是網(wǎng)絡(luò)模塊自身的流量限制導(dǎo)致。而技能實現(xiàn)機制的改善，考慮到改動的成本，最終使用了一種RPC機制，讓服務(wù)器腳本可以調(diào)用客戶端腳本，并且支持傳入復(fù)雜參數(shù)。然后策劃通過一些關(guān)鍵數(shù)據(jù)在客戶端計算出特效、動作之類。
此外，程序?qū)⒏嗟募寄軐傩詮V播給客戶端，一個客戶端上保存了周圍角色的技能數(shù)據(jù)，從而可以進(jìn)行更多的客戶端邏輯。這一塊具體的修改當(dāng)然還是策劃在做（我們的腳本策劃基本就是半個程序員）。后經(jīng)測試，效果改善顯著。
二
在策劃制作了一個PVP競技副本后，服務(wù)器在10V10測試過程中又表現(xiàn)出CPU負(fù)載較高的情況。這個問題到目前為止依然存在，只不過情況略微不同。
首先是觸發(fā)器生命周期的問題。觸發(fā)器自身包含最大觸發(fā)次數(shù)、存留時間等需求，即當(dāng)觸發(fā)一定次數(shù)，或超過存留時間后，需要由程序自動刪除；另一方面，觸發(fā)器可以是定時器類型，而定時器也決定了觸發(fā)器的生命周期。這一塊代碼寫的非常糟糕，大概就是管理職責(zé)劃分不清，導(dǎo)致出現(xiàn)對象自己刪除自己，而刪除后還在依賴自己做邏輯。
但這樣的邏輯，最多就是導(dǎo)致野指針的出現(xiàn)。不過，這種混亂的代碼，也更容易導(dǎo)致BUG。例如，在某種情況下觸發(fā)器得不到自動刪除了。但這個BUG并不是直接暴露的，直接暴露的，是CPU滿了。我們的怪物AI在腳本中是通過定時器類觸發(fā)器驅(qū)動的，每次AI幀完了后就注冊一個觸發(fā)器，以驅(qū)動下一次AI幀。由于這個BUG導(dǎo)致觸發(fā)器沒有被刪除，從而導(dǎo)致服務(wù)器上觸發(fā)器的數(shù)量急劇增加。但，這也就導(dǎo)致內(nèi)存增長吧？
另一個巧合的原因在于，在當(dāng)時的版本中，觸發(fā)器是保存一個表里的，即定時器類觸發(fā)器、屬性類觸發(fā)器、移動類觸發(fā)器等都在一個表里。每次任意觸發(fā)器事件發(fā)生時，例如屬性改變，都會遍歷這個表，檢查其是否觸發(fā)。
基于以上原因，悲劇就發(fā)生了。在這個怪物的AI腳本里，有行代碼設(shè)置了怪物的屬性。這會導(dǎo)致程序遍歷該怪物的所有觸發(fā)器。而這個怪物的觸發(fā)器數(shù)量一直在增長。然后就出現(xiàn)了在很多游戲幀里出現(xiàn)過長的遍歷操作，CPU就上去了。
找到這個問題了幾乎花了我一天的時間。因為腳本代碼不是我寫的，觸發(fā)器的最初版本也不是我寫的。通過逐一排除可能的代碼，最終竟然發(fā)現(xiàn)是一行毫不起眼的屬性改變導(dǎo)致。這個問題的查找流程，反映了將大量邏輯放在腳本中的不便之處：查起問題來實在吃力不討好。
修復(fù)了這個BUG后，我又對觸發(fā)器管理做了簡單的優(yōu)化。將觸發(fā)器列表改成二級表，將觸發(fā)器按照類型保存成幾個列表。每次觸發(fā)事件時，找出對應(yīng)類型的表遍歷。
改進(jìn)
除了修改觸發(fā)器的維護(hù)數(shù)據(jù)結(jié)構(gòu)外，程序還實現(xiàn)了一套性能統(tǒng)計機制，大概就是統(tǒng)計某個函數(shù)在一段時間內(nèi)的執(zhí)行時間情況。最初這套機制僅用于程序，但考慮到腳本代碼在整個項目中的比例，又決定將其應(yīng)用到腳本中。
這個統(tǒng)計需要在函數(shù)進(jìn)入退出時做一些事情，C++中可以通過類對象的構(gòu)建和析構(gòu)完成，但lua中沒有類似機制。最初，我使用了lua的調(diào)試庫來捕獲函數(shù)進(jìn)入/退出事件，但后來又害怕這種方式本身存在效率消耗，就取消了。我們使用lua的方式，不僅僅是全局函數(shù)，還包括函數(shù)對象。而函數(shù)對象是沒有名字標(biāo)示的，這對于日志記錄不是什么好事。為了解決這個問題，我只好對部分功能做了封裝，并讓策劃顯示填入函數(shù)對于的字符串標(biāo)示。
除此之外，因為觸發(fā)器是一種重要的敏感資源，我又加入了一個專門的觸發(fā)器統(tǒng)計模塊，分別統(tǒng)計觸發(fā)器的類型數(shù)量、游戲?qū)ο髶碛械挠|發(fā)器數(shù)量等。
END
到目前為止，導(dǎo)致服務(wù)器CPU負(fù)載過高，一般都是由BUG導(dǎo)致。這些BUG通常會造成一個過長的列表，然后有針對這個列表的遍歷操作，從而導(dǎo)致CPU負(fù)載過高。更重要的，我們使用了這么多的腳本去開發(fā)這個游戲，如何找到一個更有效合理的監(jiān)測方法，如何讓程序框架更穩(wěn)定，則是接下來更困難而又必須去面對的事情。