■サーバーの負荷問題の解決の見通しはついているのですか？

[Zhar]

(´・ω・｀)
まだ続くのか、負荷を言い訳にした検討しています祭りが……orz

言い訳じゃなくて、正直に話してるだけでしょうｗ
サーバー回りの処理は本当にセンシティブなので、それなりにスキルの高い人がやらないといけない
（＝出来る人が限られるので、進行はどうしても遅くなる）ということだと思います。
まあ、最初にそんな大事な部分まで外注に出しちゃった経営判断がイカれてるんですけどｗ

あと、vbsnbkさんも仰ってますが、通信量と通信処理量は違います。
負荷について語るならこの辺は知識として持っておくべきかと。
超ざっくりと言うと、8byteの通信を1回行うより、1byteの通信を8回行う方が、処理としては「重い」ってことですね。

[Zhar]

確実に軽くなってますね。ご担当の方【よくやった！】
インスタンスレイドも、FF11の初期ナイズル・サルベのような不安定さや重さは感じませんでした。
正直、これは予想よりかなり良いと思いました。絶対ラグラグになって緊急メンテだと思ってましたから（失礼ｗ）

ただ今日も、人の多いウルダハでPT編成中に着替えると2分程アクションの読み込みで固まってしまいました。
とまあ、まだまだ高負荷には弱いように感じましたので、引き続き頑張って下さい。

サーバーに関するスレッドで技術的なこと以外何を語ればいいというんだｗ

ご自分の分からない話をされるのを嫌う方っていらっしゃると思いますので、そういうご意見かと受け取りました。
が、私個人的には、分かる方だけに向けた話をする方がラクですから、スタンスを変えるつもりは一切ありませんがｗ

[kinokonoyama]

8ヶ月もたっていまだにプログラマーがシステムを見直しているレベルなんです
どう改修するかを決めるだけで5年くらいかかりそうな気がしますね

[Poice]

そういえば通信量が増えてラグになるって前提で話してましたが（私だけかもしれませんが）、
サーバーの計算能力（ダメージ計算やらＭｏｂのAIなどで）が足りてませんでした。ってことになったりしませんかね？
その場合はエリアをさらに小さく分割したりするのかしら？（確か三国はそうしましたよね）
それとも一つのエリアを複数の鯖で管理なんてできるんでしょうかね

鯖のプログラムに無駄がありすぎて鯖がいっぱいいっぱいになっているんだとしたら、まさしく根幹から手を付けないといけなくて一朝一夕では解決しそうにない気がします。しかも無駄な計算をしているところを特定し効率上げるのって大変そう・・・地道な努力の積み重ねが必要みたいな

[RemingtonSteele]

そういえば通信量が増えてラグになるって前提で話してましたが（私だけかもしれませんが）

私もそんな前提です。
ただ過去に「データ量減らせばいいんじゃない？」的なコメントをしたら全否定されました。
実際はどうなんでしょうね。
まあ、様々な要因があるからこそ、簡単には解決できないんでしょうが。

[vbsnbk]

私もそんな前提です。
ただ過去に「データ量減らせばいいんじゃない？」的なコメントをしたら全否定されました。
実際はどうなんでしょうね。
まあ、様々な要因があるからこそ、簡単には解決できないんでしょうが。

全否定と取られてしまったのでしたらごめんなさい。
データ量を上手く減らせばその分処理しなければいけないサーバ負荷も減りますので、無関係である
とまでは言えないのですが、現在の通信量（Windows上で実際に測定出来るフリーのツールがありますので
興味があれば探してみると良いと思います）を測定した限りでは、ラグい時もそうではない時も、通信量そのものは
そう大きく変動がなかったりします。ウルダハやBWといった比較的PC/NPCが多いエリアでも余り人の居ない
エリアでもそうなので、通信に掛かる時間的コストは恐らくラグの根本的な原因ではないかな、と判断されるわけですね。
もし通信コストが原因の場合ですが、
１：一人ひとりのユーザの回線をFF14の通信が圧迫する場合
　観察される通信量はラグが酷くなるに従って急増するかと思われます。
２：接続するユーザが増えてサーバ回線の帯域を使い尽くす場合
　限られた帯域を多人数のユーザーで分け合うので、一人あたりの通信量は少なくなります。これが酷くなると
通信途絶、回線落ちになりますが、クライアント側の負荷でも落ちることはあるでしょうから、回線落ちイコール
サーバー帯域の問題と判断するのは早計かと思われます。

このいずれの事象も起きていないようなので、今のところは通信量が大きな原因だとは考えにくいかと
思われます。もっともこの通信量の測定をしたのは4月の中頃なので、今測定したら違う傾向なのかもしれませんが。

この辺きちんと開発サイドで解説するか、雑誌やゲームポータル系のサイトのインタビューで扱ってくれたりすると
嬉しいんですけどね。まだ「どう対処すれば劇的に改善されるか」までは突き止められてないから、公にアナウンス
する段階ではないんでしょうね。

[feifong]

データ量を上手く減らせばその分処理しなければいけないサーバ負荷も減りますので、無関係である
とまでは言えないのですが、現在の通信量（Windows上で実際に測定出来るフリーのツールがありますので
興味があれば探してみると良いと思います）を測定した限りでは、ラグい時もそうではない時も、通信量そのものは
そう大きく変動がなかったりします。ウルダハやBWといった比較的PC/NPCが多いエリアでも余り人の居ない
エリアでもそうなので、通信に掛かる時間的コストは恐らくラグの根本的な原因ではないかな、と判断されるわけですね。
もし通信コストが原因の場合ですが、
１：一人ひとりのユーザの回線をFF14の通信が圧迫する場合
　観察される通信量はラグが酷くなるに従って急増するかと思われます。
２：接続するユーザが増えてサーバ回線の帯域を使い尽くす場合
　限られた帯域を多人数のユーザーで分け合うので、一人あたりの通信量は少なくなります。これが酷くなると
通信途絶、回線落ちになりますが、クライアント側の負荷でも落ちることはあるでしょうから、回線落ちイコール
サーバー帯域の問題と判断するのは早計かと思われます。

興味を惹いたので、レスが滞って久しいスレッドに投稿させて頂きます。

回線に流れるデータ量を測定していません。　ラグは、端末に届く通信データ量じゃなくレスポンス速度ですよ。
単に端末で観測できるデータ量が少ないからサーバ関係ないってのは間違い。
あるアクションに対して、レスポンスがどの程度の時間で戻ってくるかです。
サーバがヒートアップしてくると、逆に端末に届くデータ量は、単位時間に対して減る傾向がでます。

あるピッチャーが１人います。　その人はボールを４０００個持っています。　そしてキャッチャーは４０００人いました。
ピッチャーが１秒間に１００回ボールを投げれた場合、順繰りにキャッチャーへボールを投げたら１０秒間に１個づつ投げられますよね。
ピッチャーは０秒でキャッチャーからの返球を受け取れたとしましょう。　この場合は、レスポンスタイム（ラグ）が１０秒以上という事になります。

さて、じゃあピッチャーは何で１００個しかボールを投げられないのか？
原因は色々と考えられると思います。
0. システム性能がソフトウェアが要求する性能を満たしていない（スラッシングやオーバヘッド：流石になさそう）
1. サーバのハードウェアスペックとソフトウェア効率（計算と変数へのコミットが追いついていない）
2. 通信データ量が肥大して、サーバからの送信が追いつかない（計算は完了しているけれど、レスポンスが返せない）
3. 故意に送信を規制している（何らかの輻輳予防が働いている）
4. 泣きそうな見落としがある（ゲームサーバ以外がゲームサーバを邪魔している。ルーティング輻輳、中途半端なハードウェア故障）

ゲームをプレイした感触でいえば、元々通信データのペイロードを潤沢に大きく設計し過ぎている感触を持ちました。
加えて、送信データの取捨選択がなされていない。　視界範囲やミニマップに見える範囲の動的データを無条件で垂れ流している気がします。
過去に当たったパッチに「ミニマップ上の光点が異常な動きをする」不具合があったと記憶しています。
これって取捨選択を入れたらクライアントが思わぬ動きをしたのかと推測しました。
11だと遠くのPC/NPCはレーダーに映りません。　遠隔サーチでも座標とID(=NPC名)位です。

14だと1キャラクタを表現する為に必要な情報が増えてます。　装備部位、LSチャンネル、キャラクタの造形パタン、HP/MPパラメータなど多彩です。　他にも殆ど変化しないデータ（店の商品リスト、リーヴ種類）も通信データに乗せている様子があります。
ログイン直後のラグが酷い点を観ると、描画データのロードにも時間が掛かっている様子があります。　ここはエリアをシームレスにした副作用かもしれません。（ラグの割にグラフィックボードのファンの回転数が上がらない）
あと周りに人が多い、天候が悪化するとファンの回転数が上昇する。（ファンの人数が増えるとグラフィックボードのファンも嬉しくて高回転する？）
クライアントのスペックが足りていないのが悪いという問題じゃないですがね。　描画の精細さを荒い設定にしても、やっぱり重いですから。　５年後の性能向上を基本値に定めるのは方針かもしれませんが、性能不足な現状でも満足に動かせる設定を用意していない点は設計が甘い。

フレッツNext回線を基本とし、グラフィック性能は1000京ポリゴン/msecと定めて設計して、ついてこれないのはユーザが悪い、性能要求を満たすハードウェアがない世界が悪いので切り捨てます。　妥協案はありません。

これは仕様不良ではないと言い張れても、設計不良とは言えないかと。

じゃあ、どうすれば良いのか？　そんなの知らん。。。

何か、仕様書からテスト仕様書、テスト項目まで一切なく、テスト証跡だけを見せられて、一切説明しないSE/PGにレビューしている気分になってきた…

追記
パッと思いついたのが、何かの理由で実質上の意味なくサーバとクライアントの同期を取っていて、それがラグに見えてしまっているだけかも？

[vbsnbk]

長文に対する長文のレスなのでお互いに意味を掴み切れていない部分が有ったらごめんなさい。

回線に流れるデータ量を測定していません。　ラグは、端末に届く通信データ量じゃなくレスポンス速度ですよ。
単に端末で観測できるデータ量が少ないからサーバ関係ないってのは間違い。
あるアクションに対して、レスポンスがどの程度の時間で戻ってくるかです。
サーバがヒートアップしてくると、逆に端末に届くデータ量は、単位時間に対して減る傾向がでます。

そうですね。
キャラ固有のデータは恐らくそのキャラクターが最初に画面に出たときのみサーバから読み込まれますので、
画面内のキャラ（もしかしたら同じエリアサーバ内に存在するキャラ全てかも）が常に激しく出入りしているような
状況でも無い限り、通信帯域を圧迫するほどのデータのやりとりにはならないと思われます。
#というか、私のコメントはキャラの固有装備のデータの細かさがラグの原因では…というコメントに対するレスですね。キャラ装備データなんかはどんな複雑なアイテムでも通信に乗っかるのはそれぞれの内部ID程度ですので、
一人のキャラの表示情報の通信に占めるコストなんてのは知れたものかと。
　勿論サーバ側のデータベースからユーザデータを読み込む訳なのでコストが掛からないとは言えないですが、リアルタイムのバトルデータを計算してそれぞれに反映させるというエリアサーバの処理に比べれば大きな問題では無いかと思われます。

ゲームをプレイした感触でいえば、元々通信データのペイロードを潤沢に大きく設計し過ぎている感触を持ちました。
加えて、送信データの取捨選択がなされていない。　視界範囲やミニマップに見える範囲の動的データを無条件で垂れ流している
気がします。

これもそうなんでしょうね。ただ一定のデータを常に流して（サーバ上のデータを先読みして）いるので、画面内に表現されている情報量の
割りには通信量の変動が激しく無いとも言えるから、メリットもありデメリットも有りという所でしょうか。

追記
パッと思いついたのが、何かの理由で実質上の意味なくサーバとクライアントの同期を取っていて、それがラグに見えてしまっているだけかも？

例えば攻撃モーションとHPの増減の間のずれ、と見えるのがこれなんじゃないかと思いますね。
攻撃結果の数値がサーバからクライアントに渡される時点では当然サーバ上でHPの増減は計算反映済みな訳なので、
HPのパラメータが正しく同期されているからこそ攻撃モーションの前にHPが減っているように見えるという……(苦笑)。

[ponkotu]

良きプログラマは良き数学者になれと言われるほど、計算式をシンプルに、かつ構造的に優れたものにしなければ軽くはなりません。
つまり、回りくどい計算をして処理をかける事をいかに減らすかと言うことが重要なのです。

なので今回の問題は、単純労働のように時間と予算を入れ込めば何とかなるものではなく、アイデアと頭脳の勝負なのです。
皆さんイライラしてると思いますが、事はそう簡単にはいかない問題で劇的に改善するのはありえないと思っていてください。
出来るのならとっくの昔にやっています。