解決呼叫執行時間過長


log如下:

object /adm/daemons/convertd: eval_cost too big 1000000

 

執行時段錯誤:*Too long evaluation. Execution aborted.

 

程式:adm/daemons/convertd.c 第 171 行

呼叫來自:feature/command.c 的 command_hook() 第 66 行,物件: clone/user/user#35470 ("香蕉(banana)")

呼叫來自:cmds/skill/exert.c 的 main() 第 30 行,物件: cmds/skill/exert ("0(0)")

呼叫來自:adm/single/simul_efun.c 的 notify_fail() 第 126 行,物件: adm/single/simul_efun ("0(0)")

呼叫來自:adm/daemons/convertd.c 的 output() 第 171 行,物件: adm/daemons/convertd ("0(0)")

object /adm/daemons/securd: eval_cost too big 1000000

 

 

還有大量的類似的log

此類問題,只有在晚上玩家掛,大量機器人時才可能出現,白天沒機器人時根本不

會出現。。。。

 

 

 

 

作者:llm  發表時間:2001年7月4日 08:51

 

-------------------------------------------------------------------------------

 

 

Too long evaluation. Execution aborted這類的錯誤有兩個解決辦法,

一是如果你的主機性能及網絡帶寬足夠好的話。在MUDOS里的opation文件里,

將各種限制數值調大。調多大我也沒經驗,可以一步一步放大看看。然後重

新編譯再執行。

 

 

二如果你的主機不行的話,那麼只好限制玩家的一次性指令輸入數量。具體

可以在/feature/command.c裡面做。

 

 

 

 

 

作者:darks  發表時間:2001年7月4日 11:11

 

-------------------------------------------------------------------------------

 

*Too long evaluation. Execution aborted.

 

 

這個問題一般出現在函數或者呼叫執行時間過長,這裡就要注意算法,儘量保證不要再一次調用或者呼叫中使用太

多的循環,可以考慮分步執行的方式來避免。

 

 

比如先用一個函數 來執行一部分功能 然後結束這次呼叫

 

然後再調用一個呼叫 繼續執行。 有點類似INPUT_TO的做法 不過具體做起來 可不要使用

input_to  :)

 

 

有時候 交給物件自己呼叫也是一個可行的辦法。這個時候,初始的呼叫可以停止。而讓物

件自身繼續這個過程。

 

 

 

作者:hxsd  發表時間:2001年7月4日 11:37

 

-------------------------------------------------------------------------------

 

 

    上面的原因我也知道。。

    hammer2 darks..

    但這樣的程序太多了,我不可能一個一個的改吧....

    我想找個辦法,在底層上做點限制或別的什麼,就能解決這個問題....

    有沒有高招啊...

    希望darks,高人出點高招吧....

    如果要一個一個改的話,希望darks,來幫我一起改幾天吧,我估計有

一半的cmds,和幾百個room要重做....

 

有沒有辦法在底層上做一點if,或別的什麼解決以上二個問題啊....

 

 

 

 

作者:jackyboy  發表時間:2001年7月4日 21:20

 

-------------------------------------------------------------------------------

 

 

從你描述的情況看,應該是玩家的機器人大量掛機導致系統變慢,處理命令效率降低後無法在規定時間內完成呼叫

而產生的。darks,llm這點說的很清楚了。

 

 

所以可以用幾個辦法使這種錯誤不再出現:

 

 

1、增加一次呼叫的超時控制,可以去修改mudos的配置文件config,在文件里尋找這樣的字樣:maximum evaluation

cost : 1000000

 

 

然後把具體的數值修改一下就行,當然,直接修改MUDOS也是方法之一,而且肯定奏效。

 

 

2、第一個方法只是一種迫不得已的辦法,最根本的原因是要降低系統負荷。掛機是最應該被限制的行為了。那是一

種自私的,毫不顧忌搶掠的手段。:)所以至少應該在/feature/alias.c里對輸入命令速度進行控制。比如用計時

和計數方式來限制一秒內可以執行命令次數,超過的一律拋掉。這樣就應該能減少大部分的錯誤了吧。系統負擔也

應該邊小了一些。

 

 

--以上轉載自www.niub.net之mud製作論壇