問題タブ [scalability]

より多くのパフォーマンスが必要なプロジェクトに取り組んでいます。時間の経過とともに、(スレッドと分散の両方で) より並列に動作するように設計を進化させ続けてきました。その後の最新のステップは、その一部を 16 コアの新しいマシンに移動することでした。共有メモリ モデルでこれほど多くのコアにスケーリングする方法を再考する必要があることがわかりました。たとえば、標準のメモリ アロケータでは十分ではありません。

人々はどのリソースを推奨しますか?

これまでのところ、Sutter のコラム Dr. Dobbs が良い出発点であることがわかりました。The Art of Multiprocessor Programming と Intel Threading Building Blocks に関する O'Reilly の本を手に入れました

私は特にドキュメント ライブラリに興味がありますが、一般的な SharePoint リストに関して、次の質問に答えてくれる人はいますか?

1. SharePoint リストに含めることができるアイテムの最大数はいくつですか?
2. 1 つの SharePoint サーバーがホストできるリストの最大数はいくつですか?
3. リスト内のアイテム数が最大に近づくと、フィルタリングは遅くなりますか? もしそうなら、それを改善するために何ができるでしょうか?

一般に、アプリケーションを適切にスケーリングするには、どのような設計上の決定が必要でしょうか?

(注: Big O Notationについて学んだばかりなので、ここでプログラミングのより多くの原則を収集しようとしています。以下の私自身の質問に答えて Big O Notation を説明しようとしましたが、コミュニティにこの質問と両方を改善してもらいたいです。回答。）

これまでの回答
1) スケーリングを定義します。仮想環境で多数のユーザー、トラフィック、オブジェクトをスケーリングする必要がありますか?
2) アルゴリズムを見てください。彼らが行う作業量は、実際の作業量 (つまり、ループする項目の数、ユーザー数など) に比例しますか?
3) ハードウェアを見てください。アプリケーションは、1 台のマシンが追いつかなくなった場合に複数のマシンで実行できるように設計されていますか?

二次的な考え
1) あまりにも早く最適化しすぎないでください - 最初にテストしてください。思わぬところでボトルネックが発生するかもしれません。
2) スケーリングの必要性がムーアの法則を上回らない可能性があり、ハードウェアのアップグレードはリファクタリングよりも安価になる可能性があります。

通常、データベース サーバーは、垂直方向のスケーリングが唯一のオプションであるため、購入する必要がある最大かつ最も高価なボックスです。水平方向 (つまり、複数のコモディティ マシン間) に適切にスケーリングできるデータベースはありますか? また、このアプローチの制限は何ですか?

Microsoft の WCF で構築された Web サービスが多数のユーザーにどれだけうまくスケーリングされるかについて、経験のある人はいますか?

私が考えているレベルは、アプリケーションのビジネス ロジックを提供する WCF サービスのコレクションに接続する 1000 人以上のクライアント ユーザーの領域であり、これらは従来の 3 層アーキテクチャと同様に、データベースと通信します。

パフォーマンスを低下させた特定の問題や、このレベルのスケーラビリティを可能にした設計上の教訓はありますか?

ページの読み込みを可能な限り軽減するよう努めています。ViewStateはページの100kまで膨らむことがあるので、完全に排除したいと思います。

他の人がViewStateをカスタムプロバイダーに移動するために使用したいくつかのテクニックを聞きたいです。

とはいえ、いくつかの注意点があります。

• 1時間あたり平均200万人のユニークな訪問者にサービスを提供しています。
• このため、データベースの読み取りはパフォーマンスの重大な問題であり、ViewStateをデータベースに保存したくありません。
• また、ロードバランサーの背後にいるため、どのソリューションも、ポストバックごとにマシン間でバウンスするユーザーと連携する必要があります。

アイデア？

Solaris で Java と C++ を組み合わせたアプリケーションを使用しています。コードの Java の側面は、Web UI を実行し、通信しているデバイスの状態を確立します。C++ コードは、デバイスから返されるデータをリアルタイムで処理します。共有メモリは、デバイスの状態とコンテキスト情報を Java コードから C++ コードに渡すために使用されます。Java コードは、PostgreSQL データベースを使用してその状態を保持します。

かなり深刻なパフォーマンスのボトルネックに直面しており、現時点でスケーリングできる唯一の方法は、メモリと CPU の数を増やすことです。共有メモリの設計により、1 つの物理ボックスにこだわっています。

ここで本当に大きな打撃を受けたのは、C++ コードです。Web インターフェイスは、デバイスの設定にほとんど使用されていません。私たちが本当に苦労しているのは、一度構成されたデバイスが配信するデータ ボリュームを処理することです。

デバイスから返されるすべてのデータには、デバイス コンテキストを指す識別子が含まれているため、それを調べる必要があります。現在、Java/UI コードによって維持され、C++ コードによって参照される一連の共有メモリ オブジェクトがあり、それがボトルネックになっています。そのアーキテクチャのため、C++ データ処理を別のマシンに移すことはできません。デバイスのさまざまなサブセットをさまざまなマシンで処理できるようにスケールアウトできるようにする必要がありますが、その場合、そのコンテキスト ルックアップを実行する機能が失われます。これが私が解決しようとしている問題です。デバイスコンテキストを参照しながら、他のボックスへの時間データ処理。

デバイス自体が使用するプロトコルを制御することはできず、状況が変わる可能性はありません。

クラスターにマシンを追加してスケールアウトできるようにするには、これを回避する必要があることを認識しており、私はこれをどのように行うかを正確に検討している初期段階にあります。

現在、Java コードをスケールアウトする方法として Terracotta を検討していますが、それに合わせて C++ をスケールアウトする方法についてはまだ考えていません。

パフォーマンスのスケーリングだけでなく、高可用性も考慮する必要があります。アプリケーションはほぼ常に利用可能である必要があります。絶対に 100% ではなく、費用対効果が高くありませんが、マシンの停止を乗り切るための合理的な仕事を行う必要があります。

私に与えられた仕事を引き受けなければならないとしたら、あなたは何をしますか?

編集: @john channing から提供されたデータに基づいて、GigaSpaces と Gemstone の両方を調べています。Oracle Coherence と IBM ObjectGrid は Java のみのようです。

（私は.NET開発者ではなく、他の環境に縛られていないことを明確にすることから始めます。）

最近、ロンドン証券取引所が丸一日下落したと聞きました。また、ソフトウェアは.NETで作成されていると聞きました。この時点まで、彼らは忙しい日にパフォーマンスの打撃を経験するでしょう。人々は.NETを非難しているようです。

この話については議論したくありませんが、.NETはどのように拡張できるのかという疑問が浮かびました。.NETには大きすぎますか？

私は最近、 SQLiteとMySQLに関するこの質問を読みましたが、SQLiteの拡張性が低く、公式Webサイトのようなものでこれを確認しているという回答がありました。

SQLiteはどの程度スケーラブルであり、その上限は何ですか？

私のチームは、Web フロントエンドを備えた新しいサービス指向の製品を開発しています。どのテクノロジーを使用するかについての議論では、JBoss アプリケーション サーバー、Flex フロントエンド (Adobe AIR を使用したデスクトップ展開も可能)、およびクライアントとサーバーをインターフェースする Web サービスを実行することに決めました。

ビジネス ロジックにどのサーバー テクノロジを使用するかについては、行き詰まりに陥っています。大きな議論は EJB3 と Spring の間であり、最大の関心事はスケーラビリティとパフォーマンス、そしてコード ベースの保守性です。

ここに私の質問があります：

1. EJB3 対 Spring の賛成または反対の議論は何ですか?
   • それぞれにどのような落とし穴がありますか?
   • 良いベンチマーク情報はどこにありますか?