goodgames
30-01
最終更新:
goodgames
-
view
サーバ需給バランス
■ゲームモードとマップの関係
ここのところ、関連して良く話題に上るのが下記2点。
- OperationMetro専用機がほとんど無くなった
供給スロット数が漸減しており、64スロット機に至っては2013/06/30正午現在、2台のみとなっております。
(他に60スロット機が稼働している模様)
(他に60スロット機が稼働している模様)
- TDM専用機が激増している
上記リンク先サイトではゲームモード別の集計を行っていませんが、
稼働しているサーバには相当数のTDM専用機が含まれています。
稼働しているサーバには相当数のTDM専用機が含まれています。
それもNoshahr Canals専用機が多数稼働しています。
64スロット機が少ないため総スロット数ではConquestのOperationMetro専用機とトップ争いを繰り広げて(?)いますが、
稼働台数では圧倒的な状況となっており、国内サーバ総稼働台数の約20%を占めることもあるようです。
稼働台数では圧倒的な状況となっており、国内サーバ総稼働台数の約20%を占めることもあるようです。
最新SPM統計(9th Period (DLC EndGame Released))によれば、
Game mode | Map Name | Average SPM |
Conquest | Operation Metro | 566.597 |
TeamDeathMatch | Noshahr Canals | 627.111 |
このようにTDMのNoshahr CanalsはConquestのOperationMetroをSPMで10%以上上回ります。
またTDMに於いてDLCを必要としない他のマップと比較すると、
Noshahr Canalsは40%程度他のマップのSPMを上回ります。
またTDMに於いてDLCを必要としない他のマップと比較すると、
Noshahr Canalsは40%程度他のマップのSPMを上回ります。
昨今の新規プレイヤーブームを考えると高SPMマップに人気が集中するのも理解出来ます。
TDMのNoshahr Canalsは以前よりコアなファンが多いことでも知られており、
アンロック目的の高SPMに期待している層のみが集中しているとは考えにくいところですが、
コアな方々も戦闘機会の多い高密度マップを好む傾向があるのは間違いないでしょう。
アンロック目的の高SPMに期待している層のみが集中しているとは考えにくいところですが、
コアな方々も戦闘機会の多い高密度マップを好む傾向があるのは間違いないでしょう。
Conquestのように遠くまで移動してから戦闘が発生するのではTDMの目的とは異なると思いますので...
尚、需給バランスはどちらも完全崩壊状態にあり、
ConquestのOperation Metroはゴールデンタイムなら全機10人待ち状態。
TDMのNoshahr Canalsはゴールデンタイムでも閑散としたサーバが残されている状況です。
ConquestのOperation Metroはゴールデンタイムなら全機10人待ち状態。
TDMのNoshahr Canalsはゴールデンタイムでも閑散としたサーバが残されている状況です。
■RSPリソースと稼働スロット数の関係
相変わらず需給バランス崩壊状態が継続中です。
経験的には国内サーバが正常に稼働する上限は3,500スロット程度と考えられますが、
4,500スロット前後が常時稼働しており、30%以上リソースが不足していると考えて良いでしょう。
4,500スロット前後が常時稼働しており、30%以上リソースが不足していると考えて良いでしょう。
この月末に解約がほとんど発生していないところを見ると、
ラグ問題の自然解消は期待出来ないのでラグが酷いサーバの管理者の方は
「お引っ越し」(*1)などなどの対処をお勧め致します。
ラグ問題の自然解消は期待出来ないのでラグが酷いサーバの管理者の方は
「お引っ越し」(*1)などなどの対処をお勧め致します。
(*1)
御不明な方はこのブログ内(このページ内ではなくブログ全体を対象とした)検索機能で
「お引っ越し」あたりの単語を使って検索すると
抜本的(?)なラグ対処法について記載したページが見つかるはずです。
御不明な方はこのブログ内(このページ内ではなくブログ全体を対象とした)検索機能で
「お引っ越し」あたりの単語を使って検索すると
抜本的(?)なラグ対処法について記載したページが見つかるはずです。
ここのところRSPより「バックエンドパラメータ調整」なる対応を行うことで
ラグ対策を行った旨の連絡を受けるケースがあるようですが、
これはVMの各仮想ノードに対するリソース割り当ての優先順位またはその度合いを変化させるだけですので、
「無いパイの奪い合い」を強化するだけにとどまります。
ラグ対策を行った旨の連絡を受けるケースがあるようですが、
これはVMの各仮想ノードに対するリソース割り当ての優先順位またはその度合いを変化させるだけですので、
「無いパイの奪い合い」を強化するだけにとどまります。
その結果、他の競合者(つまり別のサーバ管理者)にも同じ「バックエンドパラメータ調整」が実施されれば、
逆にパイが奪い返されますので、近未来にまたラグが悪化することになります。
(一時的にでも改善すれば良いのかも知れませんが)
逆にパイが奪い返されますので、近未来にまたラグが悪化することになります。
(一時的にでも改善すれば良いのかも知れませんが)
( - )