• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            loop_in_codes

            低調(diào)做技術(shù)__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

            談?wù)勎覀兊挠螒蜻壿嫹?wù)器實現(xiàn)(二)

            原文鏈接: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)定,則是接下來更困難而又必須去面對的事情。

            posted on 2012-04-25 16:55 Kevin Lynx 閱讀(4193) 評論(2)  編輯 收藏 引用 所屬分類: game develop

            伊人久久大香线蕉精品不卡| 欧美粉嫩小泬久久久久久久 | 中文字幕无码久久久| 精品久久久一二三区| 狠狠色婷婷久久一区二区三区| 91久久精品视频| 久久天天躁狠狠躁夜夜avapp| 国产午夜福利精品久久| 国产激情久久久久久熟女老人| 久久99精品国产一区二区三区| 中文字幕久久亚洲一区| 久久免费视频观看| 久久夜色精品国产噜噜亚洲AV| 久久久久久A亚洲欧洲AV冫| 久久久久久毛片免费播放| 久久久久久免费视频| 青青草国产成人久久91网| 无码人妻久久久一区二区三区 | 97精品依人久久久大香线蕉97| 久久99亚洲综合精品首页| 国产精品久久影院| 亚洲国产美女精品久久久久∴| 久久免费99精品国产自在现线| 久久r热这里有精品视频| 99久久精品费精品国产一区二区| 国产色综合久久无码有码| 一97日本道伊人久久综合影院| 国内精品久久久久久麻豆 | 伊人久久五月天| 中文字幕久久精品| 亚洲午夜久久久久久久久电影网 | 久久精品一区二区| 九九99精品久久久久久| 久久国产精品一国产精品金尊 | 久久亚洲AV成人出白浆无码国产 | 久久久精品人妻一区二区三区蜜桃 | 欧美一区二区三区久久综合| 99精品久久久久久久婷婷| 色妞色综合久久夜夜| 久久精品国产亚洲AV久| 欧洲精品久久久av无码电影|