既存のPT募集掲示板とCFのシステムからしか見てないので深くは分かりません。
結局のところどういった経緯で吉田さんが言ったホストタイプ？で5〜60万人殺到したらダウンするの開発者さんからの詳細説明でも無ければ分かりませんね。
鯖統合かＰＴ募集を別鯖からでも入れるようにしてほしい
Printable View
-
10-01-2015, 12:47 PMMisatoMisa
-
10-01-2015, 12:50 PMNico_rekka
そもそもボトルネックは募集の数なの？
まずは何がボトルネックになってるかわからないと
どーしよーもないとおもう
アクセス回数の可能性だってあるわけだし
（こちらの方が圧倒的に増える）
読み込み処理や時間・そのほか負荷がが影響してるかもしれないし
運営のみぞしる -
10-01-2015, 01:03 PMParadice気にしてるポイントととして他も考えてねってのは、負荷なんて少ないはず、開発がサーバ云々を言い訳にするのがおかしいっていう部分のことなんでQuote:
Originally Posted by naruse
零式のマッチングという点とPT募集板の機能をごっちゃにしちゃダメよってとこです :-) -
10-01-2015, 01:09 PMNico_rekka
因みに気になっているのは
今の募集掲示板も読み込みエラー起こすんですよね
取得に失敗したのであとからアクセスしてくださいみたいな
それがクライアント要因かサーバー要因かは特定できませんが
今でもなにかネックになってる要因が潜んでるのでは？ -
10-01-2015, 04:12 PMRan-Ran
長々と仕様書いたりしてるけど、現在のCFのマッチングプログラムと具体的な負荷状況について把握した上で語ってるの？
それとサーバ間PT募集としか発言が無いけど、もしかしてエレメンタルDCからチョコボに対して募集出来る様にしろって言ってるの？
外部の人間が「こうすれば出来るはず」って言ってもそれは願望の域を出ないし、やれるとしても同一DC間になるんじゃないですかね。
どういう前提で語ってるのか分かりません。 -
10-01-2015, 05:09 PMMoMoN
まずはDC単位でのPT掲示板位はやって欲しいですね :D
-
10-01-2015, 05:19 PMZhar
まあ、「実装から透けて見える仕様」みたいなものも、あるにはあるので、色々な予想は出来ますが
実際の機器構成、NW構成、ソフトウェアの仕様なんか開発以外知る術が無いのですからねえ
普通に考えてボトルネックは参照数とキャッシング速度ですから、吉田さんが仰る
「機器追加すりゃ出来るけど、カネかかるから無理」って発言の方が説得力ありますね。
何かRDB前提で書かれている方がいらっしゃいましたが、その時点でもう技術選択から間違ってると思わなくもｗ
いっそ、こういう技術ネタを開発側から開示してもらうというのも、外野のIT屋としては楽しいですがフォーラムネタではないですね。
技術ネタをあまり書くと何故か怒り出す方もいますし。（私も旧フォーラムで噛みつかれたことがあります:p）
ここは一つ、IT系のサイトとか、雑誌とかにスクエニの方が記事書いてくれるとうれしいですね。
「FF14のバックエンド構成に迫る！」みたいな感じでｗ
FF11の頃は今は無きDBマガジンに記事が載ってたりしたので、期待しています。 -
10-01-2015, 06:45 PMSKK
他に解決案があればカネかかるから無理でも問題ないと思うんですよね
解決方法なんて一つじゃないだろうし -
10-02-2015, 12:51 AMyaaan
途中から、技術的な話になってきて疑問になったこと。
素人なので難しいことは分からないのですが、、、
スクエニ社員でもないのに、『今でもそんなに負荷がかかってないからできる』って、なんで言い切れるんだろう？と不思議に思うんですよ。
サーバー性能って、全世界全部同じだから？
スクエニさんがが、どういう風に運用してるのか、どんなプログラムソースで構築されてるのかって、なんで分かるんだろう。
分からなくても、設計はどのMMOでも『必ず一緒』だからなんです？
MMOは一般的に...みたいな感じで、『推測論』で語られてるのか、スクエニさんがどこかで詳しく公開されてる情報から『今のサーバーだけでできる』と言い切れてるのか。
サーバー追加しなくてもできるという根拠が推測論ではなく、言い切れるほどの絶対的な理由が知りたいです。
どうやってスクエニさんの正確な運用状況が分かったのか。
(ハッキングしたから...とかじゃないですよね？？？) -
10-02-2015, 01:59 AMaqua_steve
そういえばPT募集掲示板って最初無くて2.1とかで実装されたんだっけ
あくまで想像だけれど聞いてる感じだとPT募集機能自体それなりのサーバーが必要でとなると
ログインオンラインの時に追加したサーバーの見積もりにこそっと上乗せしたというか
ちょっぴり出た余剰分でまかなったのかなぁとか
まあ実際問題としてサーバーとか追加で投資するんならまずハウジングとか
需要の大きい所優先なんでしょうかねぇ
どうしたって高難易度コンテンツって参加人数全体からしたら少ないですしねぇ -
10-02-2015, 03:59 AMTheel
ざっざっと見るに、事実上「零式をCF対応に！」スレのように思えます。
PT募集を鯖横断でできるようになったとしても、FC募集やFATE、モブハン等に使う人が居るとは思えませんし、CFコンテンツはそのままCF使えばいいわけで、そうなるとCF対応外コンテンツで募集が多い零式以外に需要が無いように思えます。
もうこの時点で全体の何％だ？という気がしますし、その僅かな人のために巨額の投資をするのは普通に考えて割に合いません。
しかも「CF対応に！」という要望と「PT募集の形でないといけない」の差があやふやです。
募集が乱立しているのもを見ても、多くはミスマッチが原因で「Aさんの募集とBさんの募集を合わせればすぐに出発できるのに…」という感じも多々あります。
ナニカシラ考えがあってCF対応にしていないわけで、その辺のミスマッチは「ユーザー間で」というのが運営の現状でのスタンスに思えます。
それを超えて要望するだけのものがイマイチ感じられません。
「零式をCF対応に！」ではダメなのか？
PT募集の形式でなければならない理由は何のか？
CF対応ではダメだからこそこのスレがあるのでしょうが、CFではイケない、妥協できない点は何なのでしょう？
そしてその条件は数％以下の需要に投資するだけのものに見合いますか？
その辺を踏まえないと、運営を説得するのは難しいと思います。 -
10-02-2015, 05:11 AMaqua_steve
CF対応＝緩和みたいな部分はあると思うから単純なCF対応では無理だと思いますよ
それこそ偏ったPT構成でも攻略できる程度には調整しないと難しいでしょうからね
あと需要としては僅かだとしても(あくまで全体から見てね)僅かだからこそ
その僅かな人達が参加しにくく僅かがもっと僅かになったらコンテンツ自体成立しにくくなりますから
FF14にとって最難関レイドの重要性を考えたら何かしらの対策が必要というのは運営も認識しているものと思うであります
過密鯖の解消とか諸々考えたら単純な必要としている人達の割合だけでは考えられないものですよね
(過密のチョコボがサーバーとして破綻したらサービス自体危なくなりかねませんからね) -
10-02-2015, 12:35 PMnoton-noton＞言い切れるQuote:
Originally Posted by yaaan
確固たる証明はできませんが、募集の数、同時接続の数、サーバー数、そして必要となるサービスの内容から推測しています。
処理が一番負荷がかかるのは、コンテンツを処理しているサーバーと推測されます。
ユーザーの動きに合わせて、大量のデーターが送受信されます。高速のレスポンスが要求される為、一般のWEBサービスと異なり、システムが高価である理由です。
いっぽう、募集ですが、募集を立てる作業に大量の通信は発生しません。普通のホームページの登録と同じです。
ではPT募集に関して
もし、募集一覧を表示して、「株価チャート」のように随時変化するものを作ろうとすると、大変なコストが発生します。
ですが、マーケット・募集 は、リアルタイムに変化していません。
ので「普通の掲示板」と同程度しか送受信が発生しません。
さらに、CFと同じような形であれば、参照すら発生しません。
CFのマッチングは、DB（もしくはオンメモリ）と行われるわかですが、「裏」で動かせるので、サーバーの規模に合わせて動かせば済みます。
数万件程度のマッチング作業など、一瞬で終わるでしょう。 これがシステムを飛ばすような負荷になるとは考えにくいですね。
１分に１回程度、マッチングをおこない 成立した順に、「シャキーン」処理をおこなう事になると思います。
（コンテンツ側の負荷が大きくなっていれば、このマッチング速度を落とすことで調整）
・募集作業に通信が大量に発生していない-＞負荷は上がらない
・CRは同期動作ではないため、ユーザーとの通信が発生しない-＞負荷は上がらない
・現状募集が集まらない程、参加人数が減っているのに、システムに負荷がかかるような状況に突然なるような事は考えにくい。
それでも考えられる負荷対策
募集しても、すぐには全体募集に登録しない（クライアント側で制御）
ローカルで登録内容が変わったら停止。（ローカルでの募集を優先）
例えば：最低二人そろっていないとワールド登録が機能しない等
パッチ直後の混雑時には、停止する。 -
10-02-2015, 12:44 PMnoton-noton
仮にサーバーが必要だとしても、上にあるサービス内容から、必ずしもハイエンドである必要は考えにくく、過疎鯖対策の為、その程度のことはやって欲しいというのが、この要望の趣旨です。
過去の「サーバーが…」という吉田氏に意見を否定するわけではありませんが…
高難易度レイドの影響で、過疎鯖から「レイド挑戦プレイヤー」が移動していく状況まで想定していたのでしょうか？
もし、それが想定外なら、サーバーを追加してでも対策して欲しいと思います。 -
10-02-2015, 12:54 PMChilulu「少し遅れたけど初見同士でコンテンツ遊びたい」っていう需要が、少数だけどありますね。Quote:
Originally Posted by Theel
数は少ないけど「ローペースで遊びたい人」「効率度外視で楽しみたい人」向けの場が、
今まで一応用意されてはいたけど、人が少なくて稼動しなかったんですよね。
それがちゃんと稼動するようになるっていうことは、満足度に対する影響も大きいんじゃないかと思ってます。 -
10-02-2015, 04:40 PMnaruse2.0時およびパーティ募集時の説明では、「CFと言うものにまず慣れてもらうために、あえてパーティ募集は2.1にした」と言っていましたね。Quote:
Originally Posted by aqua_steve
なので、サーバー費用とか導入時期は関係が無い（はず）ですよ。 -
10-02-2015, 06:03 PMnaruse「前回の結果を取得中」というエラーメッセージから推測するに、F5連打による負荷増大のための対策で、Quote:
Originally Posted by Nico_rekka
クライアント側に意図的に入れてるんだと思います。 -
10-02-2015, 06:24 PMnaruseプログラミングの世界はだいたい数学で動いているので、想定されるユーザー数や必要な通信内容を考えると、Quote:
Originally Posted by yaaan
設計がだいたいどうなって、どのくらいのサーバー必要か、どんな困難さがあるのかは想像がつきます。
もちろん具体的な設計によって実際に耐えられる負荷は変わるのですが、アクセスが集中するとあらかじめわかっていれば対策をするわけで、
対策手法は限られているので、他の部分の設計がどうであれ、落ち作るところは似通ってきます。
これが皆さんの言う「読み込みならそんなに大変では無いはずだ」という意味です。
参考までに大変な例を挙げると、フリーカンパニーのチェストとかですね。
なお、話がプログラミングの世界から外れるとこの限りではなく、DCをまたいでサーバー募集となるとどのくらい大変なのかは、
物理的な要素が増えてくるので外部からだと推測が尽きづらくなってきます。
もっとも、個人的には役割が違う以上サーバーは分けると思いますが、それはアクセスが集中するからではないので、
別の「コストに見合う恩恵が一部の人であれ本当にあるのか？」って方を議論した方がよいかと思います。 -
10-02-2015, 07:30 PMnaruseわたしが設計するなら、ですけれど、Quote:
Originally Posted by MisatoMisa
鯖間募集用サーバーがあるとして、募集主であるユーザーとそのサーバーの接続は繋ぎっぱなしにしますかね。
そうして、人が集まったかとかはサーバーから募集主に送るようにします。
この場合、募集中の数が増えると使用メモリは増えますが、募集に人が参加したときにのみ通信が発生するので処理負荷はあまりありません。
（CFのシャキ待ち状態はおそらくこんな感じの設計）
一方、参加する側は今のパーティ募集と同じように、リロードしたときに読みに行くようにします。
自分の所属するワールド外のサーバーにつなぎに行く点は違いますが、
マーケットボードやパーティ募集と設計的には本質的な違いはないと思います。
なお、エリアの負荷ですが、ロビーエリアを用意しない場合はエリア自体には負荷はかからないと思います。
というのも、FF11はLSやtellの通信がキャラが現在いるエリアを経由して届いていたように見えるのですが、
FF14ではLSやtellの通信はそれ専用のサーバーを経由して届いているように見えるので、
それと同様、ユーザーとサバ缶募集サーバーを直接繋げば良いからです。
これ以外に、その募集に参加した人が募集主及び他の参加者と会話するためのチャットが必要で、
ユーザーからはパーティ会話に見えるのでしょうが、仕組みとしてはこのためのチャットチャンネルが新規に必要になりますね。
物理的には鯖間募集サーバーに相乗りになるでしょうが。 -
10-02-2015, 08:27 PMsizaku
お二方の意見が開発側に受け入れられればその案は通りますが。
その前にCFがある以上、CFサーバー間でのパーティー募集メニューを作る意味がないってことです。
そもそものパーティー募集ができた理由が抜けてますし・・・・・(;´･ω･)
そのサーバーのユーザー間でのID攻略やフェイトなどのエリアでの交流ですよ。
CF間パーティー募集にしたら交流じゃなくCFと同じになるだけです。。。
そもそも開発側が決めることです、出来るとかやれるとかユーザーの言うことではないです。
フォーラムは提案とフィードバックの場です。
お二人の案は強く反対します。
後は開発コメント待ちですね。
ユーザー間でいいあらそっても決まらないので・・・・・(;´･ω･)
ロビーサーバーの負荷割り当ての問題もある。
サーバー間での交流を減らしてでも他のサーバーとのパーティー募集が必要か？
吉田Pが社長の前でサーバー増設頼んでるのに減らすためのサーバー合併はないでしょうし。
開発側がの回答を求む。 -
10-02-2015, 09:11 PMNivalis全面的に同意ですQuote:
Originally Posted by sizaku
簡単に書いていますが例えばサーバーを超えたチャットを現状のまま実装するとなると２サーバー間ですら最低通信量３倍になるかと思います。
自分がいるサーバーでのPTチャットの通信+相手サーバーへ送る＋相手サーバー上での通信。
新規でチャット用サーバー作ったとしてもPT募集中ですらCF参加中と同じだけの負荷がチャット用サーバーにかかるのは明白ですね、、、
また、セッションなどの制限もあるかと思いますので無制限にはできないかと思います。
マクロでスキルを使用できることから下手するとスキル使用の情報をチャットサーバー介している可能性もありますし、介しているとすれば
実装することによってラグなどひどくなる可能性もあります。
人数がある程度まではふつうにできるかもしれません。
ただ、規模などは運営や開発にしかわかりませんし、できるだけ問題が起きないように実装なども検討されているかと思います。
技術的にはできても、それを話して他のユーザーを混乱させることはどうかと思います。
何度か別サーバーからの募集の話自体はPLLで出ていたかと思いますので、考えてくれているとは思いますよ -
10-02-2015, 10:05 PMRan-Ran提案の一環として仕様を書いてるのでしょう。Quote:
Originally Posted by sizaku
負荷軽減の為にDC別にロビーサーバを分けたという過去の経緯をすっ飛ばして、範囲が不明確なサーバ間PT募集を出来る様にしろの一点張りですからね。
実装してくれるなら嬉しいですが、特定コンテンツ限定で実装するかはユーザの立場では分かりません。
そもそもPT募集は特定コンテンツ限定ではありませんしね。 -
10-02-2015, 10:59 PMLuckyBancho
仕様の提案も、出来るようにしろというのも、要望やフィードバックとしては問題ないんです。
建設的な議論になり難くしているのは、stzakuさんの言ってる
この部分なのですよね。Quote:
Originally Posted by sizaku
なぜ無理なのか、難しいのかを考えたり想像するのは、問題の構造を理解する動機になります。
そこが整理できれば、筋の良いアイデアが出たりするかもしれません。
運営が情報を開示してない以上、いろいろな前提や情報に見落としや限界はありますが、建設的な議論が出来れば、少なくとも参加者全体の問題への理解は進みます。
問題なのは、「出来る(と自分が思っている)ことをしないのは、運営が自分達を騙そうとしていたり、能力が低いからだ」と、問題の構造ではなく、人の問題に結びつけてしまう態度だと思います。
悪者を作ることで話は単純になり、彼らを非難することで、彼らが反省して心変わりすれば問題が解決するような気になりますが、実際には本当の問題からは遠ざかっていきます。
社会問題で極端な主張をしているのは、自分からはこんな感じに見えるので、自分はそういう論調で主張する人と議論するのは苦手です。 -
10-02-2015, 11:44 PMnoton-noton>その前にCFがある以上、CFサーバー間でのパーティー募集メニューを作る意味がないってことです。Quote:
Originally Posted by sizaku
私のサーバーでは、それ（サーバー間PT募集）が無いから都会鯖へ移動していく固定メンバーがいました（半固定事の移動）
アレキH３層攻略中でしたが、欠員が埋まらない為、練習にならない という理由です。
意味が無いわけはないんですよ。
その機能を待っている人がいます。
私は、フォーラムで強く働きかけることぐらいしかできませんから、ここでの発言で頑張ってます。
＞そもそも開発側が決めることです、
そんなことを力説されましても、当たり前ではないですか？
決めてもらうために提案しているのです。 -
10-02-2015, 11:54 PMnoton-noton＞簡単に書いていますが例えばサーバーを超えたチャットを現状のまま実装するとなるとQuote:
Originally Posted by Nivalis
そういう負荷が予想される事は、書いていませんが？
書いてもいない事で「負荷がかかる」と主張されても…
＞ 自分がいるサーバーでのPTチャットの通信+相手サーバーへ送る＋相手サーバー上での通信。
CFで普通にPTチャットできてますから、新規の問題は無いのでは？
＞ また、セッションなどの制限もあるかと思いますので無制限にはできないかと思います。
ゲームのシステムとは既に通信中で、WEBページの様にページ切り替わりで切断したりしませんから、関係ありません。
仮にアリア移動やコンテンツによって、そういった動作をしているとしても、PT募集とは何ら関係ないでしょう。
移動先は「コンテンツサーバー」内に限られます。
既存のシステムで今動いている事を、もう少し観察されると、何が新規に必要かが判断できると思います。
その２点については、おそらく問題はないと思われます。 -
10-03-2015, 12:00 AMnoton-noton＞負荷軽減の為にDC別にロビーサーバを分けたQuote:
Originally Posted by Ran-Ran
ロビーサーバーは常にアクセスが集中し、また高速のレスポンスが要求差される場所です。（DB参照も発生します。）
募集・CFマッチングは、そういう高速なレスポンス性は要求されません。 -
10-03-2015, 12:30 AMNivalis技術的な話に関してはここでしても意味がありませんが、Quote:
Originally Posted by noton-noton
現状のまま→コストをかけずに
CFでふつうにチャットができてますから→PT募集の分も含め負荷につながります。
セッションなどの制限→ユーザー間サーバー間のセッションのほかサーバー間どうしもセッションの制限に引っかかります。
一つのセッションだけでサーバー間どうしの通信をすべて賄うことはできません。そんなことしたらラグで動かなくなります。
1000台くらいクライアント＆数台のサーバー管理ですら気を使うのに、、、、
上記のようなことはどうでもいいのです。
言いあっても実際どういう風に実装されているかなんて正確なところはわからないんだし、わからないからこそユーザーができるできないを判断すべきではありません。
要望などはどんどん言っていいと思いますよ？ ただ、技術的な事に関しては下手に知識知っているだけ（正確な構成を知らない）のユーザーが突っ込むべきことではないと思います。
ちなみにセッション数とコネクション数は似ているようで全くの別物です。
コネクション数は1でもセッション数は4とかざらにありますし、接続が確立していてもセッション数は動的にかわります。 -
10-03-2015, 01:26 AMyaaan
返信し辛い流れで恐縮です。
Quote:
Originally Posted by noton-noton
お二人とも、丁寧な説明ありがとうございました。Quote:
Originally Posted by naruse
素人でも分かるように噛み砕いていただき、感謝しております。
こういう技術的な部分のお話を聞くのが大好きで、、、。
また、他の方には若干スレ違な方向？になって、申し訳ない。 -
10-03-2015, 04:10 AMZhar
一つ確認ですが、notonさんの目的としては、現状のCF、PFよりも機能を落としてでも、ワールド間のマッチングを行う機能が欲しいという要望ですよね？
その提案自体は、私も賛成です
私自身、固定メンが欠けた日に野良で補充して３，４層の練習をするのは極めて難しいという現実に直面していますので
で、あるならばですが、おそらくnotonさんが思い描いている「システム」では、notonさん自身の要求仕様が満たせないように思えます。
Quote:
Originally Posted by noton-noton
Quote:
Originally Posted by noton-noton
Quote:
Originally Posted by noton-noton
というご認識のようですが、「裏」とは一体何でしょうか？
オンメモリで展開？そのメモリはどのサーバーに持つのですか？現状のワールドサーバーにそのような余裕があるとは思えません
DBを使う？今の計算機の資源の中で、最も「遅い」ものはストレージですよ？「DBにアクセスした時点で負け」です
マッチングの処理自体が問題にならないのは仰る通りですが、仮想化でも無い限りそもそもCPUパワーは余力があるのが普通です
そこが「軽い」からといって、「システムの値段が下がる」理由にはなりません。
大規模サーバーの見積もりを取ったことがありますか？CPUなんか、何使ってもクッソ安いですよ。
お値段が跳ね上がるのは、メモリ・ストレージ・ネットワークです。
ですので、開発に対して「リーズナブル」なシステムを提案したいのであれば
そこが軽量になる仕様をまず考える必要があると思います。
私自身は、そういうアイデアが思いつきませんので、吉田さんの「カネかかる」発言は
「ああ仕方ないなあ」という感じで諦め気味に聞きましたが
もしnotonさんが、何か良いアイデアをお持ちであれば、前述の3要件（メモリ・ストレージ・ネットワーク）に
カネがかからない仕様を再度お考えになってはどうでしょうか。 -
10-03-2015, 05:41 AMnoton-noton
Zherさんへ
＞裏
リアルタイムにユーザーの挙動にレスポンスしている部分を表
そうでないものは裏と定義しています。
ロードバランスに接続されたAPサーバー郡から、共有データーを司る（データー鯖）にユーザーの位置情報が置かれていくと仮定します。
募集のデーターを作成し、登録ボタンと同時にデーター鯖のメモリ上にスタックします。
PTへの応募も同じようにメモリ上にスタックします。
ユーザーと連動していないAPサーバーが、この情報をマッチングさせます。(非同期動作）
その後、シャキーん処理をおこないます。
マッチング処置はバッチ処理ですから、状況に応じて処理数の調整が可能です。
何度も書いていますが、このような場合のシステムはハイエンドである必要がありません。
＞現状のワールドサーバーにそのような余裕があるとは思えません
1募集に必要なメモリは１ｋbにも満たないと思われます。
１００００万件で１０Mbです。余裕ではないでしょうか？
ーーーーーーーーーーーーーーーーーーーーーーーーーー
Nivalisさんへ
＞チャットでセッション
＞コネクション数は1でもセッション数は4とかざらにありますし、接続が確立していてもセッション数は動的にかわります。
常時接続ですし、チャットメッセージ毎に毎回セッションを張るような設計にはしないでしょう。
サーバーセンターで物理的にも近いネットワーク環境なら、SANで高速通信環境を整えて、メッセージストックに、スタックしていくだけではないですかね？
（そして定期的にユーザーへメッセージを送る）
そもそも、私は全鯖にメッセージが通るようなロビーを要求した事はありません。
PTが組まれた後のPTチャットは既存のシステムで実現していますから、特別にこの件で追加が発生することは無いと思います。 -
10-03-2015, 07:20 AMNivalisだれがいつチャットメッセージを送るごとにセッションをはりなおすといったのでしょうか？Quote:
Originally Posted by noton-noton
既存のシステムに組み込むとしたらセキュリティの関連から募集のチャットだけを別にするという事はないと思います。
つまり、集中的に通信をしているサーバー経由、ユーザーのセッションは増えません。
但し、新しく組むにしても、既存のシステムを利用するにしてもサーバー間のセッションは増えます。
また、職、ILなどといった情報はどうするのですか？
最大人数の決まっているCFのシステムの1枠分は募集した段階で占有されてしまうのではないですか？
募集が多いのでIDへ入れません
納得できますか？
また、サーバー間PT募集の通信だけ迂回させて接続はセキュリティ上しないでしょう
あとはCF枠を使わないように新しく作るしかありませんが、何処まで修正が必要なんでしょうかね？
開発にしかわかりません。
尚、解ってない方に説明するほど面倒な事はありませんのでこれ以上は返信しません。 -
10-03-2015, 08:44 AMSilvershark意味のない技術的な話はやめませんか？Quote:
Originally Posted by noton-noton
noton-notonさんもシステムを何も知らないのに自分の想定が正しい的な書き込みは専門的知識がない人に混乱させるだけ
全鯖にキャラ作ってGTの時間毎の募集の発生／募集の消化／キャンセル等々を監視しない限りそんな
想定はできないですよ。その程度の情報を見たところでも大した推測はできないですけど。
(ぶっちゃけどの程度の数字で推測したか聞きたいですがやめときます)
何かの公開情報をもとにした推測ですか？Quote:
Originally Posted by noton-noton
1KB未満でどの程度の負荷だから10MBは余裕という推測ですか？
早急にCF対応して周制限はどうするの？自分たちはこんな形にしてほし！こんな形のは嫌だとか話せば良くないですか？ -
10-03-2015, 08:55 AMMisatoMisa
詳細スペックはスクエニが公開しないとわかりませんね。
PT募集&CF複合システム出来ませんかでいいような？
あとは統合のほうは単に休止者いるだけの可能性があるから、
やらないとは思う。
※3.1で復帰者いればそれだけ混乱になるかと。 -
10-03-2015, 09:23 AMnoton-noton＞既存のシステムに組み込むとしたらセキュリティの関連から募集のチャットだけを別にするという事はないと思います。Quote:
Originally Posted by Nivalis
＞つまり、集中的に通信をしているサーバー経由、ユーザーのセッションは増えません。
そうですね。ふえませんね。
＞但し、新しく組むにしても、既存のシステムを利用するにしてもサーバー間のセッションは増えます。
募集が増えればデーターのアクセスは増えるでしょう。
問題は、どのくらい増えるか？ ということではないですか？
そもそも、募集もCFもチャットなんて発生しないですよね？
＞また、職、ILなどといった情報はどうするのですか？
職 INDEXで1バイト IL余裕をもって2バイト 計3バイトです。 何か問題でも？
＞最大人数の決まっているCFのシステムの1枠分は募集した段階で占有されてしまうのではないですか？
CFの最大数が埋まるほど、アレキHに募集があるといいのですが（苦笑
＞募集が多いのでIDへ入れません
＞納得できますか？
現状＠１がこなくて2時間待ちなのですから・・・
最大コンテンツ処理数が問題になる話というのは、今回の拡張募集の件と関係ありますか？
「募集が多い」とコンテンツに入れない？ どんな因果関係があるのんでしょう？
意味不明ですね。
＞また、サーバー間PT募集の通信だけ迂回させて接続はセキュリティ上しないでしょう
ご自分で言い出して、「しないでしょうね」とはこれいかに？
サーバーとサーバー間の通信にグローバル通信が必要な前提になっているようですが、実際はSANで組まれたローカルネットワークだと思いますよ。
＞尚、解ってない方に説明するほど面倒な事はありませんのでこれ以上は返信しません。
＞また、職、ILなどといった情報はどうするのですか？＜－苦笑 -
10-03-2015, 10:16 AMnoton-notonQuote:
Originally Posted by Silvershark
＞全鯖にキャラ作ってGTの時間毎の募集の発生／募集の消化／キャンセル等々を監視しない限りそんな
こういった事は必要ありませんから、それを想定した危惧も必要ありません。
キャラを作るというのが謎ですが、必要なデーターは、キャラクターのID番号と募集に必要な付随するデーター程度でしょう。
＞1KB未満でどの程度の負荷だから10MBは余裕という推測ですか？
PT募集板で新規募集を開いてください。
・行き先 IL等の条件 募集分 募集職 募集キャラID
これにあと、募集時刻
これらから１ｋ程度と計算しています。 必要のないデータは極力省くでしょうし、募集にこれ以上のデーターは必要ないでしょう。
（同時に）１００００万の募集でも １０MB程度のメモリしか必要ないということです。
＞
そしてこのデータは「リアルタイム処理」が必要ないデーターです。
＞負荷
マッチングそのものには、通信処理は発生しないので、負荷はほぼ０でしょう。
わかりやすい例おしてエクセルを使います。
Aセルに「ナ・戦・暗・竜・モ・忍・召・黒・機・詩・白・学・占」の文字からひとつをランダムに選んで１００００行埋めてください。
データー抽出機能をセルの上部に設定してください。
ジョブを選んで表示！ 処理にどの程度かかりましたか？
Bセルに希望IDをいれてください。実際にはID番号になります
条件が幾つか増えたところで、一瞬でおわるでしょう。
例としてエクセルを使いましたが、実際にはサーバー内のメモリに直接処理をするでしょうから、CPUにとってこの程度の作業は負荷にはならないでしょうね。
※サーバーでエクセル使っているとかそういう話ではないので、念のため。 -
10-03-2015, 10:32 AMnoton-noton
＞早急にCF対応して周制限はどうするの？自分たちはこんな形にしてほし！こんな形のは嫌だとか話せば良くないですか？
募集の項目に、「外部サーバーも利用する」というチェックボックスの追加（パッチ直後、混雑時は利用できない）
募集条件の追加
１）目的：練習（初期） 練習（中盤） 練習（クリア目的） クリア済みのみ なし
２）報酬について：未クリアのみ、4人までクリア済み可、無制限
登録しても、ローカルでの募集を優先するため、3分程度は外部サーバー機能は使わない
ローカルでメンバーが追加されると、外部サーバーへの登録は中止される
募集の条件ダイアログを開くと、外部サーバー登録は中止される
CF側、登録するときに、上で追加された条件を追加情報として設定してから登録
あとは吉報を待つ -
10-03-2015, 11:10 AMAsys
内部詳細を知らない者同士で技術的な話をしたところで結論は出ない、というか現状上げ足の取り合いみたいになっているので皆で案出ししてイイと思ったら「いいね！」入れて、ここはこうした方がイイかもねみたいな意見を積み重ねていくスタンスがいいと思いますよ。
建設的に進めていければ熱意に押される形で公式にレスポンスがあるかもしれないですしね。 -
10-03-2015, 11:32 AMRan-Ranではもう一つQuote:
Originally Posted by noton-noton
これは引用の一つ前のレスにて記載した事ですが、CFのマッチングはDC内に限定しているのですが、サーバ間PT募集ってどの範囲を希望して仕様を提示していますか？
CFに対する追加機能であるとすればDC内限定になるので特定の募集ではDC内PT募集をして欲しいという要望だけで済むと思います
DCを跨いで、つまりエレメンタルやガイアのDCからチョコボや神竜に対して募集出来る様にしろ！という提案なら、データ通信の負荷状況を鑑みると無理だと運営は判断しているかと推測します。
また、別レスにてチャットは発生しないとか言ってますけど、PT募集ではチャットは発生していますよね？
PT募集では要求ILを指定した際に「禁断しているタンクは連絡下さい」といった文章も散見しますが、他サーバから参加したメンバーの装備状態を確認するのはどうお考えでしょう？
技術者気取りで色々投稿されていますが、通信方式及び通信している内容、それに伴う負荷状況全てを把握していない限り断言は出来ないと思います。
それをさも「～は出来る」と発言されていますが、パケット解析でもしたのでしょうか？
あくまで「こうして欲しいな」という要望や「実装して貰えるとすれば同一DC内で良いかと」といった提案ならともかく、不確定要素が多々ある現場で断定されては議論とはならないと感じます。
仕様に絶対の自信があるのであれば、仕様書を吉田Pに郵送した方が進展はあるかと思いますが、如何でしょうか？ -
10-03-2015, 11:56 AMSilvershark具体的にどのような数字でどのような推測をしてのか教えてください。Quote:
Originally Posted by noton-noton
必要となるサービスとはなんでしょう？数字と必要となるサービスがどのように関係してるのでしょうか？
1KB未満度いう内訳をお願いします。何がどのぐらいのサイズですか？Quote:
Originally Posted by noton-noton
余裕というのは何が余裕なのでしょうか？
あと、マッチングのバッチ処理はどのくらいの間隔で起動するんですか？
ネトゲの自動マッチングでバッチ処理ってイメージわかないです。
これぐらいの数字が出せないならいい加減なことをいうのは止めた方がいいですよ。
引っ込みつかないのは分かりますが、話題を戻そうとしてるの察してください。
自分もこれで最後にします。このスレが運営の間で笑いのネタになっていないことを祈ります。 -
10-03-2015, 12:32 PMnoton-noton逆にお聞きしたいのですが、何をすれば１ｋｂ以上のデータになるのでしょうか？Quote:
Originally Posted by Silvershark
以下見積もりです。
PT8人分のID ４X8
募集主名前文字列 ２４（いらないかも）
現在の状況
・職業 １X8
・レベル 2 x8
募集職業
職業 ４X8 （ビット利用）
平均レベルアイテムあり・なし １
必要レベル ２
募集文字列 １２８
登録日時 ４
言語設定 ４
初見～のチェックボックス ４（ビット利用）
目的のレイド INDEX ２
（数字の単位はバイト）
一般にこういったデーターは構造体というメモリブロックに入れられて、
配列処理で検索します。
１００００万件の配列検索程度は、「コンピューター」に負荷がかかるような処理ではないのです。
（これをリアルタイムにユーザーに伝えるのであれば、話は違いますがマッチング処理はそうではないからです）
上の説明でわからないなら、これ以上やさしく説明するのは無理かな。
3分程度の時間を置くのは、募集の登録をやった後、直ぐに修正など繰り返す動作が考えられるためです。
そこで3分ほど募集の内容に変更が無いことを確認してから、外部サーバーへのPT検索を実行します。
（また、サーバ内の希望者を優先するため）
こういう間隔を置いてから検索処理をおこなうのは負荷軽減で普通にあります。