問題タブ [web-garden]

Web アプリケーションを Web Garden 環境に移行する予定です。分散キャッシュを提供するために、Windows Server App Fabric Caching に傾倒しています。それは正しいアプローチですか?/Appfabric Caching 以外に分散キャッシングを実現する方法はありますか?

IIS サーバーで Web ガーデンを構成しています。

Web ガーデンにはアプリケーション プールに対して複数のワーカー プロセスがあることを知っています。つまり、要求数が制限を超えると、1 つの Web アプリケーションに対して追加の w3wp.exe が作成される可能性があります。(間違っていたら訂正してください)

上記の場合、1 つのリクエストが複数の w3wp.exe によって処理されている可能性はありますか?

また、1 つのアプリケーションに対して 2 つの w3wp.exe が作成されるかどうかについて明確にする必要がありますか? または 2 つの w3wp.exe がアプリ プール内のアプリケーションを共有します。

Azure App Service プランが、その中で定義された Web、API、ロジック、およびモバイル アプリ専用の仮想マシンである場合、App Service プラン内の Web アプリは、その仮想マシン上の IIS 内の仮想 Web サーバーのインスタンスであることを意味しますか? ?

これが事実であり、各仮想 Web サイトが独自のアプリケーション プールを取得すると仮定すると、そのアプリケーション プールで複数のワーカー プロセスが実行され、Web ガーデンが作成される Azure スケーリング戦略またはシナリオはありますか? Web アプリのスケールアウトについての私の理解では、追加のワーカー プロセスではなく、追加の VM が割り当てられるということです。

現在、キャッシュ用に MongoDB データベースを実装しています。

save メソッドが次のように機能する、非常に一般的なクライアントを作成しました。

他のクライアントでこのメソッドを呼び出すと、次のようになります。

データをバックエンドに保持した後、Get メソッドを呼び出して引数 true を渡して、MongoDB からキャッシュをリロードします。したがって、すべてのデータをリロードします。

これは、ほとんどのユースケースでうまく機能します。しかし、同じアプリケーションに対して Web ガーデン ソリューション (複数のプロセス) をどのように使用しているかを考えると、これは並行性の問題につながります。別のユーザーがページをリロードしているときにキャッシュを保存してリロードすると、E11000 重複キー エラー コレクションがスローされることがあります。

コマンド createIndexes が失敗しました: E11000 重複キー エラー コレクション: cache.Person インデックス: Id_1_Name_1_Email_1 重複キー: { : 1, : "John Doe", : "foo@bar.com" }.

これが複数の IIS プロセスが実行されている Web ガーデンであることを考えると、ロックはあまり役に立ちません。一括書き込みがどのようにスレッドセーフであるべきかを考えると、私は少し困惑しています。データのアップサートについて調べましたが、クライアントをタイプ固有に変更し、各フィールドを更新するには時間がかかりすぎて、不要な作業のように感じます。したがって、私は非常に一般的な解決策を探しています。

UPDATE 挿入と削除を削除しました。ReplaceOneModel のコレクションに変更しました。現在、コレクション内の最後の要素のみが永続化されるという問題が発生しています。

811 個のアイテムのコレクションを渡したところ、このメソッドが実行された後、最後のアイテムのみがコレクション内で見つかります。

永続化される DTO の例:

このインデックスでは:

asp.net を使用してセッションでデータを移動したい。私の質問をシナリオで説明したいと思います。

アプリケーションには 4 つのレイヤーがあります。ユーザー パスワードでポータルにログインすると、ユーザー名とユーザー ID のセッションが作成されます。たとえば、各サーバーの前に負荷分散があるビジネス レイヤー用の 3 つのサーバーがあります。このシナリオでデータ (ユーザー名/ユーザー ID セッション) を運ぶにはどうすればよいですか? または、別の方法でデータを運ぶ (セッションなし) 場合は、共有できますか? (シナリオ用に写真を追加しました。)

注: 私はソフトウェア開発者であり、このシナリオのベスト プラクティスを検索したいと考えています。

まず、私は Web アプリ プログラミングの初心者です。私はデスクトップ アプリ (WinForms & WPF) から来ました。最近、他の人が過去に作成したプロジェクトが割り当てられました。このプロジェクトは ASP.NET MVC で行われ、InProc セッション状態モードを使用します。

ここで、アプリケーション プールに複数のワーカー プロセスを使用する Web ガーデニングを構築したいと考えています。Google で検索したところ、アプリ プール内の各ワーカー プロセスが独自のセッション状態を使用するため、InProc セッションが Web ガーデニングで機能しないことがわかりました。そのため、State Server や SQL Server などの別のセッション状態モードに切り替える予定です。

今、疑問があります。Web.config でのセッション状態モードの変更とは別に:

... 追加の作業を行う必要がありますか? たとえば、ASP.NET MVC アプリ、構成、またはその他のものを動作させるために再プログラミングしますか?

以下に、興味深いリンクをいくつか紹介します。

• サーバーと SQL Server の状態の構成
• 方法: ASP.NET セッション状態を格納するように SQL Server を構成する

Web Garden の使用を避けることを推奨する人もいます。代わりに、この.

私が知る限り、Web ガーデンはプール内のワーカー プロセスの数を増やすことで構成されています。これは、着信要求を処理する複数のスレッドを持つようなものです。

プールに複数のワーカー プロセスを使用することと、MaxWorkerThreads、MaxIOThreads などのパラメーターを使用して ASP.NET web.config ファイルを調整することの違いは何ですか?

どちらも複数のスレッドを使用することで構成されているため、これら 2 つの手法の違いはわかりません。