2005年12月15日

ラグの理由

メンテの日は考察と決めとるよーこやー。
ネタありまへんけれど。
師匠はんところ手伝う代わりに色々勉強させてもろてるで今日はTSが何故こんなラグいんかちゅう話。
今回のメンテはネットワーク関係の修正言うことやけれどネットワークどんだけ太くしてもサーバ弱いであかんやろちゅうのはみんな感じてることやと思うで。
ほならなしてサーバ弱いんやろか?
こんくらいの人数やとこんくらいのサーバ必要ちゅう計算式は山ほどあるねん。
うちもシステムコンサル系の設計部門におるで待ち行列計算やらなんやらちゅうのは知っとる。
計算はできへんけれどw
やからサーバの処理能力ちゅうんはちゃんと計算して配分できるもんなんや。
つまりTS重い理由はサーバの処理能力の計算が間違っとるちゅうこと。
ほならなして計算間違えたんやろか?
師匠はんの解釈やとこれはTSで使てるコンピュータ言語の問題なんやて。
以前バグでアイテム売買で「(null)が1個売れました」みたいんメッセージ出とったやろ。
nullを"null"て文字列に変換するけったいな言語はjavaしかありえへんのやて。
やからTSがサーバサイドjava使てるんはほぼ間違いないらしいで。
ほんでサーバサイドjavaちゅう言語は師匠の言葉借りると「objectをnewするときにheapエリアのサーチが走り、領域確保できないときは暗黙的にSystem.gc()によってgarbage collectorが走るんだが、これが時間取る。さらに確保されたメモリー上にnewしたobjectを生成するときはメモリーバッティング避けるためにスレッド数に関係なくsynchronizeだから、どうしても時間がかかる」そうや。
知っとる人ならわかるんやろけれどうちにとっては呪文みたいなもんやで師匠にもっとわかりやすく教えてや!言うたら教えてくれたでー。
「つまり、モンスターキル後の湧き処理が一番時間かかるということ」らしいんよ。
たぶんTSは平均どんくらいでモンスターキルできるか色々計算して求めた数値を元にサーバの能力設定してるんやね。
ほんでそん計算が合っとる間はラグが少なかったねん。
ほならどこで計算狂ったんやろか。
最もラグを加速する職業は魔。
なんでか言うと魔が全体攻撃かますと一度にたくさんのモンス倒れる→一度にたくさんのモンスが湧く→ラグるて三段コンボが発生するから。
これ体感としてもよーわかる。
たとえば歓迎学園の教室にけつね×1ぬこ×2おって狩りしとるんとけつね×1風羊×1おって狩りしとるんと後ろんほうが圧倒的にラグるもん。
もちろんTSでも魔の全体攻撃計算に入れてサーバの処理能力計算しとるはずや。
やけれどそん計算は簡略んために全職業が均等におったちゅう仮定で作られるはずなんよ。
ほんでちょっと偏りあっても大丈夫なくらいな処理能力に設定されとるはずなんね。
ところが今のTS、魔が圧倒的に多いやろ。
つまり計算以上に職業の偏りができてもうたんやね。
そんせいで計算以上にサーバに負荷かかってラグくなってもうたちゅうのが師匠とうちの見解や。
誤解ないように言うとくけれどこれは魔が悪いちゅうわけやない。
悪いんは魔を有利にしたシステムとそんせいで魔が多くなることをサーバの処理能力計算に入れんかった運営側の問題やから。
ほなら対策は?
posted by よーこ at 13:19| Comment(12) | TrackBack(0) | トリックスター | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。