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