サーバーのポーリングは最善のアイデアではないと聞いたことがあります。
クライアント/サーバー アプリケーションを作成するとします。例えば簡単なゲーム。各クライアントが 30 分ごとにサーバーをポーリングする場所。wamp サーバーが過負荷になる前に、いくつのクライアントを持つことができますか? 基本的に、Apacheはこの種のものに対してどれほど堅牢ですか? リクエストを取得し、mysql サーバーからデータを集約し、データを xml 形式で返します。
これは本当にオープンエンドの質問です。それは完全に構成、実行しているApacheサービスの数、物理サーバーの数、mysqlサーバーのセットアップ方法(独自のマシン上にありますか)に依存しますか?また、サーバーをポーリングすることにより、毎回接続を開始し、その通信にリソースを割り当てる必要があることにも注意してください (下位レベルのネットワークとプログラムで)。
可能な限り、サーバーがコンテンツをクライアントにプッシュする方がよい場合があります (プッシュがポーリングよりも頻繁に発生しないと仮定します)。
なかなか数字が出せません。さまざまな要因 (ハードウェアを含む) に依存します。
あなたにとってより重要なことは何ですか? サポートできる同時ユーザーの数と結果のリアルタイム性は?
リアルタイムの結果を探している場合は、Cometやlong pollingなどを調査することをお勧めします。
多くのユーザーのサポートを探している場合、ロング ポーリング アプローチはおそらく理想的ではなく、おそらく Apache より軽量なものが必要になるでしょう。個人的にはnginxのファンです。
編集:そして、あなたが本当にヒップだと感じているなら、ここでリアルタイムの結果を得るための最善の策はWeb Socketsですが、マイクロソフトの男なら、IEはそれらをサポートしていないので、これはあまり役に立ちません.
私の推測では、Apache サーバーが問題になる前に、リクエストが処理しているものと mysql データベースを最大化するでしょう。
ただし、適切なキャッシュが配置され、十分にスマートなアーキテクチャと実用的な設計があり、事実上 30 秒のポーリングのみである場合は、1,000 人のユーザーをサポートできるはずです。
しかし : モックを作成し、手早く汚いものを作成し、大まかに自分がやろうと思っていることを実行し、JMeter (または同様のもの) で 3、10、30、100、300、1000、3000 などでヒットします。パフォーマンスの壁。
集約データの部分が怖いです...集約が本当に必要な場合は、DBに行く必要がないように慎重に設計してください。