問題タブ [appfabric-cache]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
appfabric - AppFabric エラー コード:
サーバーに AppFabric をインストールしました。単一のコンピューターのクラスターを作成しました。「Gagan」という名前のキャッシュも作成しました。次のコマンドを順番に使用しました
Use-CacheCluster -Provider xml -ConnectionString \NB-GJANJUA\Cache Start-CacheCluster
その結果、キャッシュ サービスが稼働中であり、これまでのところ良好です。
次に、以下のように web.config ファイルをセットアップします
しかし、サイトを起動するとすぐに、このエラーが発生します
パーサー エラー メッセージ: ErrorCode:SubStatus:There is a temporary failure. 後で再試行してください。(指定された 1 つ以上のキャッシュ サーバーが使用できません。これは、ネットワークまたはサーバーのビジー状態が原因である可能性があります。クラスター上のこのクライアント アカウントにセキュリティ アクセス許可が付与されていること、および AppFabric キャッシュ サービスがすべてのキャッシュ ホストのファイアウォールを介して許可されていることを確認してください。後で再試行してください。)
ソース エラー:
私が欠けているものはありますか?
注: Microsoft.ApplicationServer.Caching.Client および Microsoft.APplicationServer.Caching.Core アセンブリは既に参照しています。
あなたの時間と忍耐に感謝します
よろしく ガガン・ジャンジュア
session-state - 単一のWebサーバーでのInProcとAppFabricのセッション状態
状態を保存するためにセッションを大幅に利用するASP.NetMVCアプリケーションがあります(大規模なデータ収集を含む)。現在、単一のWebサーバーでホストされています。セッションはデフォルトのInProcに設定されています。
多くのユーザーがオンラインになっていると、一部のユーザーのアプリケーションがフリーズするという問題が発生します。これは、InProcセッションのスケーリングがあまり良くなく、プロセスで使用できるメモリが非常に多いためだと思います。(メモリ需要が使用可能なメモリを超えた場合はどうなりますか?ディスクにスワップアウトしますか?)
スケーラビリティに役立つソリューションをいくつか考えています。(a)SQLサーバーのセッション状態。(b)AppFabricキャッシングを使用するようにセッション状態を構成します。最初のオプションは、パフォーマンスに影響を与え、保存されたアイテムをシリアル化できるようにする必要があることを除けば、優れたソリューションのように見えます。
単一のWebサーバーがキャッシュホストとしても使用される環境でAppFabricキャッシング(別名Velocity)を使用するようにセッション状態を構成するのはどうですか?これは、この単一サーバー環境でのInProcとどのように異なりますか?これにより、InProcよりもスケーラビリティと使用可能なメモリが提供されますか、それとも基本的に同じ制約になりますか?
windows - AppFabric キャッシュと Windows 7
Windows 7 プロフェッショナル マシンで AppFabric キャッシュ クラスターを実行するための推奨事項はありますか? 3 つのノードを持ち、高可用性をセットアップする予定です。提案してください。以下は私のクライアント構成になります。
caching - クエリ可能なデータ セットに分散キャッシュを使用することは可能ですか?
私のシナリオは次のとおりです。100 万行のタプル (たとえば、名と姓)を持つデータ テーブルと、名または姓がクエリ文字列で始まる行の小さなサブセットを取得する必要があるクライアントがあります。これをキャッシュすることは、キャッチ 22 のように思えます。
- 一方では、リクエストごとにデータセット全体を保存および取得することはできません (ネットワークを圧倒します)。
- 一方、各行を個別に保存することはできません。クエリを実行する方法がないからです。
- ローカルの「インデックス」またはディレクトリを使用して、値の範囲をキャッシュに保存することは機能します... ただし、基本的に各インデックスのデータを複製する必要があり、分散キャッシュを使用する目的さえ無効になります。
この種のことにはどのようなアプローチが望ましいですか?分散キャッシュを使用する利点を得ることができますか?それとも、この種のシナリオには適していませんか?
serialization - WindowsServerアプリファブリックでのカスタムキャッシュシリアライザーの使用
Azure AppFabric( Jagan Periによるカスタムシリアル化)でカスタムキャッシュシリアライザーを使用できるようです。
Windows Server AppFabricキャッシングでカスタムシリアライザーを使用する可能性はありますか?
.net - Windows Server AppFabric キャッシュとデータベースの同期
ヘルスケア アプリケーションに Windows Server AppFabric キャッシュを使用する予定です。AppFabric キャッシュを使用してキャッシュする患者マスターとその他のマスター データがあります。ただし、SQL Server Service Broker とレプリケーションを使用して他のアプリケーションとのバックエンド統合をセットアップし、この患者マスターと他のルックアップ データを更新することもできます。Service Broker を使用してこのデータが更新されたときに AppFabric キャッシュに通知するにはどうすればよいでしょうか。これにより、キャッシュは常に最新の患者マスターおよびその他のマスター データ情報を反映します。SQL CacheDependency または SQL Server Notification サービスを使用できますか?
ありがとう、ガウラフ。
architecture - AppFabric キャッシング - リードスルー/ライトビハインド戦略
私たちの新しいプロジェクトでは、AppFabric キャッシュを重要なコンポーネントにしたいと考えています。一般的なガイドラインとして、書き込みモデル/ドメインと読み取りモデル/ドメインを用意します。バックエンド サービスはプロバイダー/その他のサービスから通知を受け、ビジネス ルールに従って一部のデータをキャッシュに入れます。フロントエンド サービス/Web サイトは、必要に応じてデータを消費します。
リードスルー/ライトビハインドは良いアプローチのようです。しかし、それを実際のビジネス ソリューションに実装するにはどうすればよいでしょうか。私が見た各例では、データをロードするために ADO.NET で単純なクエリを使用しています。私たちの場合、データの読み込みはビジネスに依存し、多くのアセンブリと対話が必要になります。すべてのビジネスを各キャッシュ ホストに展開することは、適切な解決策ではないようです。
もう 1 つのアプローチは、ドメインごとに独自のサービスを用意し、キャッシュからの取得/読み取りと、キャッシュへの書き込み/書き込みを担当することです。AppFabric キャッシュのラッパーになるため、理想的ではなく、パフォーマンスが低下します。
ご不明な点がございましたら、お気軽にお問い合わせください。
手伝ってくれてありがとう !
appfabric - AppFabric スケーリングの問題のトラブルシューティング (断続的なエラーコード):サブステータスエラー)
Web アプリケーション用に AppFabric Windows Server Cache を実装しました。最初は、問題なくキャッシュを使用できました。その後、トラフィックが約 100 倍に増加し、断続的な例外が発生し始めました。例外は、およそ 2 日に 1 回、一度に約 1 分間発生します。
私たちの構成:
- キャッシュ内のオブジェクトを挿入/取得する 9 つの Web サーバー:
- 主に一時的な 500 バイトの操作型オブジェクト
- 1 つの名前付きリージョンの使用
- タグで保存されたオブジェクト
- 特定のタグの一括取得
- キャッシュ クラスタ:
エラーは発生順に表示されます (例外は、1 分間に9 つの Web サーバーのそれぞれで発生します)。
System.Net.Sockets.SocketException : 既存の接続がリモート ホストによって強制的に閉じられました Microsoft.ApplicationServer.Caching.DataCacheException:
ErrorCode<ERRCA0016>:SubStatus<ES0001>:The connection was terminated, possibly due to server or network problems or serialized Object size is greater than MaxBufferSize on server. Result of the request is unknown. ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:15:00'. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host --- End of inner exception stack trace --- at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) at System.ServiceModel.Channels.FramingDuplexSessionChannel.EndReceive(IAsyncResult result) at Microsoft.ApplicationServer.Caching.WcfClientChannel.CompleteProcessing(IAsyncResult result) --- End of inner exception stack trace --- at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody) at Microsoft.ApplicationServer.Caching.DataCache.GetNextBatch(String region, DataCacheTag[] tags, GetByTagsOperation op, IMonitoringListener listener, Byte[][]& state, Boolean& more) at Microsoft.ApplicationServer.Caching.CacheEnumerator.MoveNext() at System.Linq.Enumerable.WhereSelectEnumerableIterator'2.MoveNext() at System.Linq.Enumerable.<ExceptIterator>d__99'1.MoveNext() at System.Collections.Generic.List'1..ctor(IEnumerable'1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable'1 source)
Microsoft.ApplicationServer.Caching.DataCacheException:
ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.) at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody) at Microsoft.ApplicationServer.Caching.DataCache.GetNextBatch(String region, DataCacheTag[] tags, GetByTagsOperation op, IMonitoringListener listener, Byte[][]& state, Boolean& more) at Microsoft.ApplicationServer.Caching.CacheEnumerator.MoveNext() at System.Linq.Enumerable.WhereSelectEnumerableIterator'2.MoveNext() at System.Linq.Enumerable.<ExceptIterator>d__99'1.MoveNext() at System.Collections.Generic.List'1..ctor(IEnumerable'1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable'1 source)
Microsoft.ApplicationServer.Caching.DataCacheException:
ErrorCode<ERRCA0018>:SubStatus<ES0001>:The request timed out. at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody) at Microsoft.ApplicationServer.Caching.DataCache.GetNextBatch(String region, DataCacheTag[] tags, GetByTagsOperation op, IMonitoringListener listener, Byte[][]& state, Boolean& more) at Microsoft.ApplicationServer.Caching.CacheEnumerator.MoveNext() at System.Linq.Enumerable.WhereSelectEnumerableIterator'2.MoveNext() at System.Linq.Enumerable.<ExceptIterator>d__99'1.MoveNext() at System.Collections.Generic.List'1..ctor(IEnumerable'1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable'1 source)
また、問題を診断するためのより多くの情報を取得するために、キャッシュ サーバーでトレースログ セッションを作成しました。これを分析する方法に関する提案をいただければ幸いです (必要に応じて利用できるようにします)。
また、さまざまな AppFabric、CLR、およびネットワーク パフォーマンス カウンターも監視しました。以下は、イベントが発生したときのスクリーンショットです。
この問題を解決するために共有できるご意見やアドバイスをお寄せいただきありがとうございます。
更新 1
以下は、断続的なエラー中に AppFabric キャッシュサーバーで継続的に発生する例外です(トレースログから抜粋)。
System.ServiceModel.CommunicationException: The socket connection was aborted because an asynchronous send to the socket did not complete within the allotted timeout of 00:00:00.0082078. The time allotted to this operation may have been a portion of a longer timeout. ---> System.ObjectDisposedException: The socket connection has been disposed. Object name: 'System.ServiceModel.Channels.SocketConnection'. --- End of inner exception stack trace --- at System.ServiceModel.Channels.SocketConnection.ThrowIfNotOpen() at System.ServiceModel.Channels.SocketConnection.BeginRead(Int32 offset, Int32 size, TimeSpan timeout, WaitCallback callback, Object state) at System.ServiceModel.Channels.SessionConnectionReader.BeginReceive(TimeSpan timeout, WaitCallback callback, Object state) at System.ServiceModel.Channels.SynchronizedMessageSource.ReceiveAsyncResult.PerformOperation(TimeSpan timeout) at System.ServiceModel.Channels.SynchronizedMessageSource.SynchronizedAsyncResult'1..ctor(SynchronizedMessageSource syncSource, TimeSpan timeout, AsyncCallback callback, Object state) at System.ServiceModel.Channels.FramingDuplexSessionChannel.BeginReceive(TimeSpan timeout, AsyncCallback callback, Object state) at Microsoft.ApplicationServer.Caching.WcfServerChannel.CompleteProcessing(IAsyncResult result)
System.ServiceModel.CommunicationObjectAbortedException: The communication object, System.ServiceModel.Channels.ServerSessionPreambleConnectionReader+ServerFramingDuplexSessionChannel, cannot be used for communication because it has been Aborted. at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) at System.ServiceModel.Channels.FramingDuplexSessionChannel.OnEndSend(IAsyncResult result) at Microsoft.ApplicationServer.Caching.ReplyContext.EndSend(IAsyncResult result)
System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Channels.ServerSessionPreambleConnectionReader+ServerFramingDuplexSessionChannel, cannot be used for communication because it is in the Faulted state. at System.ServiceModel.Channels.CommunicationObject.ThrowIfDisposedOrNotOpen() at System.ServiceModel.Channels.OutputChannel.Send(Message message, TimeSpan timeout) at Microsoft.ApplicationServer.Caching.ReplyContext.Reply(Message message, TimeSpan timeout)
System.TimeoutException: Sending to via http://www.w3.org/2005/08/addressing/anonymous timed out after 00:00:15. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: Cannot claim lock within the allotted timeout of 00:00:15. The time allotted to this operation may have been a portion of a longer timeout. --- End of inner exception stack trace --- at System.ServiceModel.Channels.FramingDuplexSessionChannel.OnSend(Message message, TimeSpan timeout) at System.ServiceModel.Channels.OutputChannel.Send(Message message, TimeSpan timeout) at Microsoft.ApplicationServer.Caching.ReplyContext.Reply(Message message, TimeSpan timeout)
更新 2
もう 1 日トラブルシューティングを行った後、次のアクションを実行した結果、いくつかの改善が得られました。
これとこれに基づいて、に増加
maxConnectionsToServer
しました3
。その結果、 AppFabric Caching:Cache パフォーマンスカウンターによって記録されたクライアント リクエスト/秒が 50% 増加しましたが、断続的なエラーの発生は止まりませんでした。キャッシュ サーバー構成で
maxBufferSize
andmaxBufferPoolSize
を2147483647
(int32.max) に増やしました。これまでのところ、エラーなしで 300 倍のトラフィック量を処理できます。今後もトラフィック量を増やして監視していきます。今後のアップデート
更新 3
それぞれ 16 GB のホストをさらに 2 つクラスターに追加し、HighAvailability モードを有効にしました ( 経由Secondaries=1
)。現在、元のホストは 96 GB の RAM を持つクラスターに残ります。すべてのホストにはcacheSize = 12
GB があります。MaxConnectionToServer
キャッシュ クライアントでは、12
(コアあたり 1)に増やします。以下は調査結果です。
- ときどき (10 分ごとに 1 回か 2 回):
ErrorCode<ERRCA0017>:SubStatus<ES0005>:There is a temporary failure. Please retry later. (There was a contention on the store.)
ErrorCode<ERRCA0017>:SubStatus<ES0004>:There is a temporary failure. Please retry later. (Replication queue was full. This may happen during reconfiguration of cluster hosts.)
- 元の 96GB キャッシュ ホストでは、前述のように 1 分間の停止が引き続き発生します。新しいキャッシュ ホストでは障害が発生していません
元のキャッシュ ホストから 80 GB の RAM を削除する予定です。さらにアップデートが続きます。
更新 4
この問題は、キャッシュ ホストの RAM の量を 16GB に減らすことで解決されたようです。トラフィックが 400x に増加すると、断続的なエラーは発生しなくなりました。ケースは閉じているようです。次の話題に移りましょう:高可用性
appfabric-cache - Windows アプリ ファブリック キャッシュ
いくつかの名前付きキャッシュを使用して Windows AppFabric キャッシュを使用しています。名前付きキャッシュごとに個別の有効期限ポリシーを設定できます。
可能であれば、構成ファイルを介してこれを実現する方法を教えてください。
サンプルコード
コードによると、3 番目のタグで指定されているポリシーは、AFCM と呼ばれる名前付きキャッシュ用であると推測されます。この点について明確にしてください。
azure - Azure でライトスルーおよびリードビハインド用のカスタム DataCacheStoreProvider をデプロイする方法
カスタムの DataCacheStoreProvider を Azure にデプロイすることはできますか? 現在、ローカルで展開してテストしようとしていますが、ドキュメントが私のシナリオをカバーしていないため、これを行う方法がわかりません。どんな助けでも大歓迎です。