問題タブ [high-load]

トラフィックの多い Sitecore サイトでは、どのような種類の定期的なメンテナンス タスクを実行する必要がありますか?

現在、私たちは:

• Sitecore、IIS、およびシステム ログでエラーを分析する
• 容量の問題について IIS ログ内の応答時間を調べる

Sitecore が正常に機能し、問題が迫っていないことを確認するために、定期的 (毎月) に実行する必要があるその他のタスクは何ですか?

私は、数週間で1回限りのトラフィックの大きなピークを送信する場所で紹介されるWebサイトを持っています。

Webサイトをホストしているサーバーは、顧客が使用するコントロールパネルもホストしています。

ウェブサイトの部分はシンプルでほとんど静的です。しかし、それはワードプレスのブログを含んでいます。

私の質問トラフィックのピークを通過できるように、Webサイトとブログをどこにどのように配置またはキャッシュできますか？たとえば、Amazon s3でページをホストして、サーバーを経由せずにドメインの通常のURLからアクセスできるようにすることはできますか？

MySQLサーバーに高負荷（1秒あたり最大960クエリ）があり、最大400のクライアントが継続的にクエリを実行しています。強力なマシン（8コア、Xeon、3.3 GHz）を搭載しており、負荷に対応できるようです。問題はありません。

時折（週に1回）、すべてのクライアントプロセスが同時にエラーになり、「不明なMySQLサーバー'XXX'」というメッセージが表示されます。それから、私が何もしなくても、彼らは皆、しばらくして生き返ります。

max_connectionsを500に設定していますが、その数を超えると、表示されているものではなく、「接続が多すぎます」というエラーが発生するはずです。

誰かが私がこれらのエラーを受け取っている理由を理解するのを手伝ってもらえますか？

ありがとう、
ジョナサン

nginx + C ++モジュールと比較して、組み込みのネイティブコードを使用して、高負荷のプロジェクト用に独自のWebサーバーを作成することをお勧めしますか？おそらく、生産性の向上はごくわずかでしょうか？

そして、このアプローチ（nginxのС++モジュール）の安全性は、解釈されたプログラミング言語の使用法と比較してどうですか？

重み付きの要素のリストがあります。

重みは小さな整数です（たとえば、1000未満、多くの場合50未満）。リスト内のIDの総数も1000未満です。（それぞれidが1回だけリストされます。）

クエリごとに、リストから「十分にランダムな」要素を返す必要があります。Eすべての重みの合計に比例するクエリを実行する場合E、各要素要素が同じ回数、 その値に正確に比例する必要があります。weightこれは、の値が小さい場合E（たとえば、最大50 *重みの合計）で機能することに注意してください。質問の最後にある注記も参照してください。

これまでのところ、要素IDを循環リストに入れ、重みを掛けて複製し、リストをシャッフルすることで、このタスクを解決します。各クエリはリストの先頭を返し、先頭の位置をインクリメントします。

しかし、この場合、もう1つの条件があります。

クエリに追加のパラメータがあります：フィルタ。フィルタはのマップですid => is_enabled。特定のに対してis_enabledfalseの場合、結果から除外する必要があります。上記の制限の値は、有効な要素に対してのみ計算されます。つまり、無効にされた要素の重みはクエリから除外されます。ididE

フィルタはクエリごとに「一意」でありid、リストにそれぞれのエントリが含まれます。（これは、2 ^ 1000の潜在的なフィルター値を意味することに注意してください。）

これを効率的に解決する方法はありますか？マルチサーバークラスターで効率的なアルゴリズムが必要です。

注1：私が信じているように、状態を保存せずに要素を完全にランダムに選択すると（回答の1つで示唆されているように）、機能しないことを強調したいと思います。無限の数のクエリに対してのみ、正確に比例した数の要素を提供します。乱数ジェネレーターには、長期間にわたって不公平な値を返す完全な権利があります。

注2：このタスクは、ランダム性の品質に制限を課しません。考えてみると、上記の単純なケースのソリューションでリストをシャッフルする必要はありません。良いランダム性の方が優れていますが、まったく必要ありません。

注3： 2 ^ 1000の潜在的なフィルター値は、フィルター値に関連付けられたものを保存できないことを意味することに注意してください。メモリが多すぎることになります。最新の（または頻繁に使用される）フィルター用に何かを保存することはできますが、そのデータを失うわけにはいかないため、アイテムリストのオフセットなどを保存することはできません。

注4：クエリでメタ情報を返したり、クライアントに状態を保存させたりすることはできません（とにかく、Diacleticusに感謝します）。2つのクライアントが誤って同じフィルターを使用する可能性があるため、使用できません（一部のフィルターは他のフィルターよりも人気があります）。この場合、両方のクエリに同じ状態を使用する必要があります。実際、クライアントが複数のクエリを実行することは、比較的まれなイベントです。

1 つまたは複数のタグでマークされた (たとえば) 投稿がたくさんあります。投稿は作成または削除できます。また、ユーザーは 1 つまたは複数のタグの検索リクエストを作成できます (論理 AND で結合)。最初に頭に浮かんだアイデアは単純なモデルでした

作成操作と削除操作の実装は明らかです。検索はより複雑です。N 個のタグを検索するには、"SELECT * FROM Post WHERE tags = :1" のような N 個の GQL クエリを実行し、カーソルを使用して結果をマージしますが、パフォーマンスはひどいものです。

2番目のアイデアは、異なるエンティティでタグを分離することです

キーごとに db からタグを取得し (GQL で取得するよりもはるかに高速)、メモリにマージします。この実装は最初の実装よりもパフォーマンスが優れていると思いますが、非常に頻繁に使用されるタグは、単一のデータストア オブジェクトに許可されている最大サイズを超える可能性があります。 . もう 1 つの問題があります。データストアは 1 つのオブジェクトを 1 秒あたり 1 回しか変更できないため、頻繁に使用されるタグの場合、変更の遅延によるボトルネックも発生します。

助言がありますか？

誰かが私に言うことができます、高負荷システムでマルチスレッドを使用するためのアーキテクチャパターンまたは方法は何ですか？多重化アプローチについて読みましたが、他に何かありますか？ありがとう。

専用のHTTPサーバーを作成する必要があります。このためにepollsycallを使用する予定ですが、複数のプロセッサ/コアを利用したいので、アーキテクチャソリューションを思い付くことができません。ATMの私の考えは次のとおりです。独自のepoll記述子を使用して複数のスレッドを作成し、メインスレッドは接続を受け入れ、それらをスレッドepollに分散します。しかし、もっと良い解決策はありますか？高負荷アーキテクチャで読むことができる本/記事/ガイドはどれですか？私はC10Kの記事しか見たことがありませんが、例へのリンクのほとんどは死んでいます:(そしてこの主題に関する詳細な本はまだありません:(。

回答ありがとうございます。

UPD：具体的に言ってください。資料と例が必要です（nginxは複雑すぎて、複数のシステムをサポートするには複数の抽象化レイヤーがあるため、例ではありません）。

私の環境: Windows Server 2008、IIE 7.0、ASP.NET

Silverlight クライアントを開発しました。このクライアントは、WCF Web サービスを介して ASP.NET ホストから更新を取得します。

ユーザー数が非常に少ない場合 (~50)、CPU 使用率が 100% になり、接続が切断されます。サーバーは明らかにそれ以上のことを処理できるはずです。

DEV サーバーでいくつかのテストを実行したところ、実際に 100 リクエスト/秒で CPU が最大になりました。奇妙なことに、サービスがハードコードされたデータを送り返すダミーに置き換えられたとしても、サービスは依然として CPU を使い果たします。スレッド数が約 20 と非常に少なく見えたので、どこかで競合が発生していると思いました。

processModel見つかったすべての構成オプションを変更して、ワーカー スレッド ( 、httpRuntimeおよびMaxRequestsPerCPUレジストリ エントリ)を増やしました。何も変わっていません。

次に、IIS サーバーを停止し、Web サービスをコンソールとして実行しました (すべての ASP 認証参照を削除しました)。このサービスは、CPU も使い果たしました。

次に魔法の部分です。コンソール アプリを強制終了し、IIS を再起動したところ、サービスは 5 ～ 60% の CPU で 100 リクエスト/秒を実行し、50 以上のワーカー スレッドを確認できます。プリプロ マシンで同じことを行ったところ、同じ魔法の効果が得られました。マシンを再起動すると、良好な動作が維持されます。

私の質問は、私の IIS サーバーを修正するために何が起こったのですか? 何がそれを修正したのか本当に理解できません。

乾杯。

私は、1 日あたり最大 5 億リクエストの容量を持つ HTTP サービスを設計しています (複数の独立したマシンによって処理されます)。

リクエストごとに、一意の ID を生成してユーザーに返す必要があります。ID は、10 分間のウィンドウ内で 100% 一意である必要があります。(1 日が推奨されます。グローバルに一意の ID が理想的です。) その ID を生成するためにサーバー間通信は必要ありません。

ばかげた疑似セッションの例:

この HTTP サービスの前の世代では、UUID を使用していました。

UUID には満足していますが、問題が 1 つあります。それは、長すぎることです。その数の要求では、この余分なサイズは、ログ ファイルのディスク領域の浪費に顕著に現れます。

短いが一意の識別子を作成する最良の方法は何ですか? 物事を価値のあるものにするために、アルゴリズムは UUID の長さの最大半分を生成する必要があると思いますが、1 日中一意である必要があります (10 分はさらに短くする必要があります)。

理想的には、提案されたアルゴリズムは、プレーンな C で正気で軽量な製品品質の実装を備えているでしょう。

更新: 生成された ID は、GET 要求で渡されるときに URI エンコードを必要としません。