1 秒あたり 60 ～ 80 件の Web リクエストを処理するには、Sitecore Web アプリケーションが必要です。Sitecore 7.0 を使用しています。1 つの Web サーバー + 1 つのデータベース サーバーの展開を試みましたが、1 秒あたり 20 ～ 25 の要求しか処理しません。Web サーバーは、メモリ内の他のすべての要求をキューに入れます。負荷を増やすと、メモリがいっぱいになります (推奨されるすべての Sitecore パフォーマンス強化を行いました)。目標を達成するには、4 倍のパフォーマンスが必要です:)。
既存のサーバーをアップグレードすることでこの目標を達成することは可能でしょうか、それとも本番環境に Web サーバーを追加する必要がありますか?
注: Lucene インデックスも使用しています。
展開の全体的なアーキテクチャを変更せずに考慮できるいくつかの事項を次に示します。
メディアと静的アセットのリクエストをオフロードする CDN
これにより、コンテンツ配信サーバーは、重要なコンテンツ クエリと表示ロジックを処理できるようになります。
Sitecore のビルトイン キャッシュを構成して使用する
これはガイドからのものです：
Sitecore キャッシュの調査と構成は、複数のタスクに分割されます。このようにして、各タスクはより集中的で簡素化されます。Sitecore データベース キャッシュ (プリフェッチ、データ、およびアイテム キャッシュ) の構成と調整に重点が置かれています。
出力レンダリング キャッシュ プロパティの構成については、Sitecore キャッシュ構成リファレンスと Sitecore プレゼンテーション コンポーネント リファレンスの両方で、これらのキャッシュを適切に有効にする方法とプロパティを有効期限切れにする方法を確認する必要があります。
Sitecore チューニング ガイドを確認してください
遅いクエリまたはコントロールを見つける
あなたのアプリケーションは Sitecore のベスト プラクティスに従っているように思えますが、この回答を見つけた人のためにこのメモを残しておきます。Sitecore のビルトイン デバッグ モードを使用して、実行速度が最も遅いコントロールとサブレイアウトを特定します。さらに、Analytics を設定している場合は、アプリケーションの速度が低下している場所に関する情報を提供する「遅いページ」レポートがあります。
以上のことを踏まえて、追加のサーバーをプロビジョニングして負荷分散環境をセットアップする準備ができている場合は、読み進めてください。
コンテンツ配信とコンテンツ管理
を分離する 私にとって、コンテンツ配信サーバーの負荷を分散する前の最初の論理的なステップは、コンテンツ管理を方程式から分離することです。これは非常に簡単で、スケーリング ガイドでは、Lucene インデックスを最新の状態に保つために HistoryEngine をセットアップする手順を説明しています。
2 つ以上のコンテンツ デリバリー サーバーでロード バランサーをセットアップする
最初のステップが完了したら、コンテンツ デリバリー サーバーのクローンを作成し、ロード バランサーの「プール」に追加するだけで簡単に実行できます。ここで考慮すべき点がいくつかあります: Web アプリケーションはユーザーのログインを許可していますか? そのため、スティッキー セッションやマシン キーについて心配する必要があります。Web アプリケーションは BLOB メディアではなくファイル メディアを使用していますか? 私はこれに対処する必要はありませんでしたが、それが別の考慮事項であることは理解しています。
SQL ソリューションのスケーリング
最大 4 つの負荷分散されたコンテンツ配信サーバーを持つアプリケーションを見てきましたが、SQL Server には問題がありませんでした。これは、SQL Server の馬力とチューニングなど、多くの要因に応じて、それぞれのケースに固有のものになると思います。 、アプリケーションのコンテンツ モデル、クエリの複雑さ、コンテンツ配信サーバーのキャッシュ構成などです。繰り返しますが、スケーリング ガイドでは SQL ミラーリングとフェールオーバーについて説明しています。
最後に、Sitecore に連絡してください。これらの人はおそらく、インストールで何がうまくいったのか、何がうまくいかなかったのかをもっと見てきたので、あなたを正しい道に導くことができます. 幸運を！