XNUMXつのASP.NETパフォーマンスブースター
録画されたウェビナー
RonHussainとNickZulfiqarによる
分散.NETキャッシュを使用してASP.NETのパフォーマンスとスケーラビリティを向上させる方法を学びます。 このウェビナーを視聴して、ASP.NETアプリケーションのスケーラビリティのためにASP.NETのパフォーマンスを向上させるXNUMXつの方法と、それらを効果的に解決するためにインメモリ分散キャッシュを使用する方法について学習してください。
シニアソリューションアーキテクトとリージョナルセールスディレクターが共同で提供する、以下について学ぶためにご参加ください。
- ASP.NETアプリケーションデータキャッシング
- ASP.NETセッション状態のキャッシュ
- ASP.NET SignalR Backplane 分散キャッシュの使用
- ASP.NET View State キャッシング
- ASP.NET出力キャッシュ
今日は、ASP.NETアプリケーションのパフォーマンスとスケーラビリティを向上させる5つの方法について説明します。 とてもホットな話題ですが、需要が高いと思います。 だから、私たちはあなたのためにこれを持ってきてうれしいです。 ロンはこれについてすぐに話します。また、このプレゼンテーション中に質問がある場合は、ビデオに自由に入力してください。ロンの注意を引くことができます。
それで、ロンあなたはどのようなことから始めますか？ ありがとう、ニック。 みなさん、こんにちは。私の名前はロンです。今日のウェビナーのプレゼンターになります。ニックが提案したように、今日選択したトピックはXNUMXつのASP.NETパフォーマンスブースターです。 そこで、XNUMXつの異なる機能について説明します。 最初に、XNUMXつの異なる問題について説明します。ASP.NETWebアプリケーション内で通常見られる問題です。これらは、アプリケーションの速度を実際に低下させる日常的な問題であり、パフォーマンスの低下です。次に、スケーラビリティは別の手段であり、別の側面です。これらのボトルネックについて説明してから、分散キャッシングシステムを使用したさまざまなソリューションについて説明します。 ASP.NETアプリケーション内でこれらの問題を解決するにはどうすればよいですか？ それが今日私たちが並べたものです。さまざまな機能について説明し、サンプルアプリケーションを用意し、これを設定して開始する方法をすべて紹介します。 それで、それはかなりインタラクティブでかなり実践的なウェビナーになるでしょう、そしてニックが述べたように、何か質問があれば気軽に飛び込んでください、そして私はあなたのためにそれらすべての質問に答えることをとてもうれしく思います。 すべてが良さそうだと仮定して、これから始めます。
ASP.NETはトラフィックの多いWebアプリで人気があります
そこで、まず、ASP.NETプラットフォーム全般について説明します。 ASP.NETは、Webアプリケーションで非常に人気のあるプラットフォームです。 多くのWeb展開が見られ、その人気は高まっています。 ASP.NETプラットフォームの良いところは、使用パターンに基づいており、非常にうまくスケールアウトできることです。アプリケーションアーキテクチャ内で何も変更することなく、何千もの同時ユーザーとそれに関連する要求を処理できます。 Webファームを作成したり、Webガーデンを作成したり、多くのスケーラビリティオプションを提供したり、ロードバランサーを前面に配置したり、異なるWebサーバー間で要求をルーティングしたりして、線形スケーラビリティ、水平スケーラビリティを実現できます。 ASP.NETWebファームから。
ロードバランサーは、Webサーバーまたはアプリサーバーのステートフルな性質に応じて、アーキテクチャに応じてスティッキーな負荷分散または同等の負荷分散を行うことができ、必要に応じてスケールアウトできます。
つまり、これはASP.NETアプリケーションの一般的なWebファームの展開であり、N個のクライアントがロードバランサーを通過してWebファーム内にWebサーバーをセットアップし、ASP.NETセッションストレージがあります。これは一種のデータです。 ASP.NETWebアプリケーション内に表示される場合があります。 次に、データベースサーバー、リレーショナルデータベース、または NoSQL database■大量のデータをやり取りしている場合は、アプリケーションが相互作用している他のバックエンドデータシステムのメインフレームファイルシステムである可能性があります。 したがって、これは非常に人気があり、非常にスケーラブルで、非常に高速であり、多くのアクティブな展開がこのプラットフォームを使用しています。
問題：スケーラビリティのボトルネック
それでは、ASP.NET内のスケーラビリティのボトルネックについて説明しましょう。 正確にはどこに問題がありますか？ これは、スケーラビリティの問題を非常にうまくスケールアウトするものであり、スケーラビリティとは何かをすばやく定義しましょう。 スケーラビリティとは、アプリケーションアーキテクチャ内、またはアプリケーションがデプロイされている環境内の機能です。 これは、パフォーマンスを損なうことなく、5000秒あたりのリクエスト数または特定のリクエスト、同時リクエストの数を増やすことができる機能です。 たとえば500,000人のユーザーの下である程度の遅延がある場合。 そのレイテンシーを維持するのはどうですか？ パフォーマンスを低下させることはなく、パフォーマンスを向上させなくてもかまいませんが、少なくともXNUMXユーザーまたはXNUMXユーザー未満のパフォーマンスを維持します。この機能自体はスケーラビリティと呼ばれ、システムから最大のスループットを引き出し、リクエストの負荷がますます増えています。処理された後、ユーザーの負荷が増加してもレイテンシは増加しません。 つまり、本質的には、極端な負荷の下でのパフォーマンス、または極端な負荷の下での極端なパフォーマンスです。 したがって、その機能はスケーラビリティと呼ばれます。
現在、通常ASP.NETアプリケーションは非常にスケーラブルですが、Webファーム内のスケーラビリティの問題が発生しますが、主にバックエンドデータソースが原因で、ピーク負荷時に速度が低下する可能性があります。 したがって、アプリケーションの速度が低下すると、大量の負荷が原因でアプリケーションが停止し、そのアプリケーションがスケーラビリティの候補となるため、アプリケーション自体にスケーラブルなアーキテクチャが必要になります。 アプリケーションがあなたの世界を感じる理由、またはピーク負荷の下でアプリケーションが遅くなるこのような状況が見られる場合、アプリケーション内にさまざまなデータストレージ定格のボトルネックまたはいくつかのボトルネックが存在する可能性があります。 したがって、この時点から、スケーラビリティの能力を制限し、スケールアウトを制限するASP.NETアプリケーション内のXNUMXつの異なるボトルネックについて説明します。
XNUMXつのデータストレージのボトルネック
大丈夫。 したがって、まず、XNUMXつのデータストレージのボトルネックがあります。
データベースを拡張できません
通常はスケールアップできないアプリケーションデータベースがあります。SQLServer、Oracle、またはその他の一般的なリレーショナルデータソースの形式のリレーショナルデータベースがあります。 ストレージには非常に適していますが、大量のトランザクション負荷を処理する場合にはあまり適していません。 窒息する傾向があり、場合によっては、実際にタイムアウトエラーが発生します。 したがって、少なくとも実際にはパフォーマンスが低下するため、データベースサーバーをその場で追加することはできないため、単一のソースになります。 また、レプリケーションがない場合は単一障害点であり、最も重要なのは、ここでの差し迫った問題は、速度がそれほど速くなく、通常のシナリオでは低速であり、ピーク負荷では低速であり、実際に状況を悪化させることです。増加した負荷に対応できず、処理速度がさらに低下します。 これが私たちの最初のボトルネックです。
ASP.NETセッション状態ストレージ
XNUMX番目のボトルネックは、ASP.NETセッション状態ストレージに関するものです。現在、セッション状態は非常に重要な種類のデータです。 これはユーザー情報を持っているものです。たとえば、ユーザー情報を管理しているeコマースアプリケーションやショッピングカート、予約システム、発券システム、金融システムなどがあります。 したがって、ユーザーがログインし、このセッションオブジェクト内に非常に重要なデータを持っている、あらゆる種類のフロントシステムである可能性があります。
現在、これらはASP.NETプラットフォームが提供するXNUMXつのモードであり、すべてがワーカープロセス内に格納されるInProcがあります。 したがって、すべてがアプリケーションプロセス内にあるため、ワーカープロセスはステートレスではなく、HTTPプロトコル自体はステートレスですが、この場合、ワーカープロセスはすべてのユーザーデータ自体をホストします。 次に、XNUMX番目のオプションであるStateServerがあり、次にSQLServerがあります。 したがって、これらの従来のセッション状態ストレージオプションについて説明し、それらのボトルネックについて説明しましょう。
まず第一に、InProcはメモリ内にあるため高速であり、シリアル化の逆シリアル化はありませんが、欠点として、まず第一に、Webガーデンのシナリオを処理できません。 XNUMXつのWebサーバーでは、特定のアプリケーションに対して単一のワーカープロセスしかありません。これは、次のリクエストが別のワーカープロセスに送信された場合にセッションデータが存在する場所であり、そのセッションデータはもう存在しないため、同じワーカープロセスである必要があります。これがあなたを制限する理由です。技術的には、InProcセッション管理でWebガーデンを実行することはできません。そのため、ここでの制限要因のXNUMXつです。
次に、ロードバランサーでスティッキーセッションビットを有効にする必要があります。 そのため、まず、Webサーバー上のパフォーマンスやスケーラビリティ、またはリソースを制限し、アプリケーションに対してXNUMXつのプロセスのみを使用します。 次に、最初のリクエストが処理されたWebサーバーでは、後続のリクエストは常に同じサーバーに送信されます。 これですべてのスティッキーセッションの負荷分散が機能し、作業は完了しますが、これに関する主な問題は、XNUMXつのWebサーバーで多数のユーザーがアクティブになっているのに、他のWebサーバーは既にログアウトされているためにアイドル状態になっている可能性があることです。ユーザーは本質的にスティッキーになるため、この無料のサーバーにアクセスすることはなく、データが存在する場所と同じサーバーに常にアクセスします。 したがって、これはInProcとのスティッキーセッションの負荷分散が必要なもうXNUMXつの問題です。最も重要なのは、ワーカープロセスがリサイクルされ、経験に基づいてASP.NETワーカープロセスがかなりリサイクルされることを確認した場合、すべてが失われることです。データの権利、それがメンテナンス関連のタスクである場合、サーバーをダウンさせる必要がある場合は、XNUMXつのWebサーバーをダウンさせる必要があり、別のWebサーバーをアップさせる必要があります。その結果、すべてのデータが失われます。 つまり、ASP.NETを使用したInProcセッション管理で発生するすべての問題とすべてのボトルネックをまとめたものです。 したがって、これは明らかにオプションではなく、あまりスケーラブルではありません。サーバーの容量に達するサーバーがXNUMXつあり、スティッキーでは負荷分散が効果的ではありません。
XNUMX番目のオプションはStateServerです。これは、State Service内のアプリケーションプロセスからデータを取得するため、InProcよりもわずかに優れています。リモートボックスまたはWebサーバーのいずれかである可能性があります。完全にあなた次第ですが、これに関する問題は、そうではないことです。スケーラブルで、単一のソースであり、そのサーバーでスケールアップできますが、スケールアウトはオプションではありません。 それは常に単一のサーバーであり、すべてのセッションデータをホストするXNUMXつのサービスであり、すべてのリクエストの負荷も管理します。リクエストの負荷が増大した場合、リソースを追加するオプションはありません。 したがって、比較してスケールアウトすることはなく、最終的には州のサービスが停止する可能性があります。たとえば、数百、数千のユーザーがいて、関連するリクエストによってXNUMX秒あたりまたはXNUMX日あたり数百万のリクエストが発生した場合、または数百万以内の場合、かなりの負荷がかかります。 。 したがって、それに基づいて、StateServerはスケールアウトせず、増加する負荷に対処できず、障害の単一のポイントにもなります。 StateServer自体がダウンした場合、すべてのセッションデータが失われます。セッションデータは、ユーザーが何かを購入しようとしているとき、または決定を下そうとしているときにセッションを失いたくない非常に重要な種類のデータであり、影響を及ぼします。見返りにビジネス。
XNUMX番目のオプションはSQLServerです。 SQL Serverもまた、プロセス外のセッション管理ですが、速度が遅く、スケーラブルではなく、SQL Serverを追加することはできず、トランザクションデータのみを処理するためのものではないため、問題の一部として説明したのと同じ問題が発生します。アプリケーションデータベースの場合、その問題はデータキャッシングでもセッションキャッシングでも同じです。 したがって、セッション状態は、ASP.NETプラットフォームが提供するデフォルトのオプションで最適化されるものではなく、これは主に、InProc、StateServer、およびSQLServerが提供するデータソースが原因です。
これによりボトルネックに関する基本的な詳細が構築されたことを願っています。もちろん、ソリューションについて説明し、分散キャッシングとその機能を比較して説明し、これらの問題をXNUMXつずつ処理する方法について説明します。 、最初にすべての問題をリストアップしてから、解決策をXNUMXつずつ説明します。 この図は同じことを示しています。
データストレージのボトルネックデータベースがあり、次にASP.NETセッションストレージまたはInProcまたはデータベースをセッションマネージャーとして使用します。これも明らかにボトルネックになります。ほとんどの場合、単一のソースがあり、スケーラブルではなく、スケーラブルではありません。非常に信頼性が高く、一般的に遅いです。
ASP.NET View State ボトルネック
現在、XNUMX番目に重要なボトルネックは ASP.NET view state。 ASP.NET Webファームにはビューステートがありますが、ビューステートとは何かを知りたい人はいますか？ 誰もが知っていると思いますが、ビューステートはクライアント側の状態管理であり、パケットであり、Webファームにあるコントロールウィジェットの状態であり、サーバー側で構築され、サーバー側の一部になります。応答パケットは、保存されているブラウザに返されます。ブラウザ側で実際に使用されることはなく、分散された要求パケットの一部としてそのページにポストバックすると、サーバーに戻されます。 したがって、要求パケットと応答パケットにバンドルされ、ブラウザに戻ります。そこで実際に使用されることはなく、ビューステートに関する差し迫った問題のXNUMXつは、一般的に非常に重いことです。 サイズは数百キロバイトで、トランザクションの負荷が非常に大きく、数百万のトランザクションがあり、各トランザクションにビューステートパケットバンドルがあるか、ASP.NETWebアプリケーションの要求応答パケットがあるシナリオを考えてみてください。ビューステートの一部であり、リクエストごとに数百キロバイトのビューステートがあり、数百万のトランザクションがある場合、多くの帯域幅を消費し、処理しているため、一般にページの応答が遅くなります。前後に大量のデータがあり、そのデータのサイズも重いです。
つまり、これは帯域幅を消費するもうXNUMXつのボトルネックであり、原因が大幅に増加し、ビューステートが一般的に重いため、ページの応答時間が遅くなります。応答の要求に対してより重いペイロードを処理します。 つまり、これはASP.NETWebファームの一部である別の種類のボトルネックです。 ASP.NET Webファームアプリケーションを使用している場合、この問題から逃れることはできません。 デフォルトでは、多くのビューステートを処理する必要があります。この図は、ビューステートがブラウザに戻る場所を示しています。これは、クライアント側の状態管理がサーバー側で構築され、ブラウザに戻ってそれをもたらすことです。ポストバックのサーバーに戻ります。 現在、要求パケットと応答パケットは重いです。それらは多くの帯域幅を消費し、重いペイロードも物事を遅くします。
余分なページ実行のボトルネック
これでXNUMX番目のボトルネックになり、これが最後からXNUMX番目になります。これが余分なページ実行のボトルネックになった後、もうXNUMXつのボトルネックがあります。 これは、ASP.NETWebファームとASP.NETMVCWebアプリケーションに当てはまります。 ページ出力全体が同じであるか、動的ページ内の一部が同じであるというシナリオがあります。そのため、アプリケーション内で静的コンテンツを頻繁に処理しています。 したがって、ページ出力はそれほど頻繁には変更されませんが、それらの要求は引き続き実行されます。 リクエストが発生する可能性があります。これには、レンダリングされるバックエンドデータベースが含まれ、バックエンドデータソースからデータをフェッチし、そのデータを読み取り、日常のビジネスロジックレイヤー、データアクセスレイヤーをすべて意味のあるものに適用します。良いものであり、その後、応答をレンダリングすると、応答はブラウザでエンドユーザーに返送されます。 これで、同じサイクルを何度も繰り返す必要があり、コンテンツが変更されない場合でも、同じサイクルを何度も繰り返す必要があります。 このページは、変更の有無に関係なく実行されます。デフォルトでは、多くの静的コンテンツを処理しており、コンテンツは変更されていませんが、同じリクエストを実行しています。 これにより、インフラストラクチャコスト、追加のCPU、追加のメモリ、追加のデータベースリソースが増加し、Webサーバーの容量に達する可能性があります。また、データベースサイトの容量に達する可能性もあります。一般に、何かを実行するために多くの高価なCPUとリソースを浪費することになります。すでに実行されています。 だから、それは別のボトルネックであり、これを処理する方法もページ出力キャッシュの助けを借りて解決策について話します。 つまり、これはXNUMX番目のボトルネックとXNUMX番目のボトルネックをカバーしています。ちなみに、この図には静的出力でのページ実行が含まれ、多くのリクエストを処理するデータベースが増えています。
ASP.NET SignalR Backplane ボトルネック
そしてXNUMX番目のボトルネックは SignalR backplane。 これは、SignalRを使用している場合と使用していない場合がある非常に特殊な使用例ですが、SignalRに精通していて、バックプレーンを設定している場合は、バックプレーンが一般的なメッセージバスであり、Webサーバーがすべてのメッセージを送信します。クライアントブラウザでプッシュ機能を送信する代わりにメッセージ。 他のWebサーバーで処理されるクライアント要求がほとんどないシナリオが考えられます。 つまり、バックプレーンとバックプレーンに順番にブロードキャストされ、メッセージがブロードキャストされ、SignalRメッセージがすべてのWebサーバーにブロードキャストされ、接続されているすべてのクライアントにブロードキャストされます。 つまり、WebSocketを使用する ASP.NET SignalR backplane Webファームがある場合、これはかなり一般的な設定です。
Now SignalR Backplane NCache または、他の分散キャッシング製品をプラグインできます。データベースまたはメッセージバスの場合もありますが、ここでの考え方は、バックプレーンにパフォーマンスやスループットの問題があってはならないということです。 非常に優れたパフォーマンスを発揮し、レイテンシーが低く、スループットが高く、同時に、ビジネスに影響を与える可能性のあるすべてのSignalRメッセージが失われた場合でも、非常に信頼性が高いはずです。
データベースは低速で、あまりスケーラブルではなく、パフォーマンスも低速です。 Redis はネイティブの.NETではないオプションなので、非常にスケーラブルで、非常に高速で、非常に信頼性の高いものが必要です。 したがって、ASP.NETアプリケーションを使用している場合、これはASP.NETアプリケーション内の別の問題です。 SignalR backplane その結果として。 これでXNUMXつのボトルネックが解消されました。多くの情報がありますが、主にデータベースが低速で、あまりスケーラブルではありません。ASP.NETセッション状態には、デフォルトで非常にスケーラブルまたは高速または信頼性の高いオプションがありません。 ASP.NET Webファームのビューステートもボトルネックであり、競合の原因であり、帯域幅の使用率が高いため、アプリケーションコンテンツが変更されているかどうかに関係なく、アプリケーション内の静的ページが実行されます。 それが実行され、それから私たちは SignalR Backplane これは一般的に低速で信頼性が低く、スケーラブルではなく、比較して非常にスケーラブルで信頼性の高いものが必要です。
これでXNUMXつのボトルネックが完了しました。次のいくつかのスライドでソリューションについて説明し、実際にこれらのボトルネックをXNUMXつずつ確認して、さまざまなソリューションを紹介します。 ご不明な点がございましたら、お気軽にお問い合わせください。今すぐお答えさせていただきます。 ここにいくつかのサンプルサンプルアプリケーションが並んでいるので、これらを使用します。 ですから、現時点では問題はないと思います。 次のセグメントでカバーすることがたくさんあるので、私はすぐにソリューションを開始します。
解決策：インメモリ分散キャッシュ
ソリューションとしてメモリ内分散キャッシングがあり、これを使用します NCache 例として。 NCache はメインの分散キャッシュ製品であり、.NETベースの分散キャッシュです。これは.NET内で作成され、主に.NETアプリケーション用であり、当社の主要製品のXNUMXつです。 使用します NCache 製品の例として、XNUMXつの異なる機能について説明します。 NCache これで問題が解決し、ASP.NETアプリケーション内でパフォーマンスが向上します。 パフォーマンスとスケーラビリティが劇的に向上します。これはASP.NET固有の機能であり、調整可能な他のサーバー側の機能があります。別のウェビナーがあります。 改善方法 NCache パフォーマンス、これでまったく新しいレベルになり、パフォーマンスがさらに向上しますが、このウェビナーでは、XNUMXつの異なるボトルネックについて説明し、次にそれらのボトルネックに対するXNUMXつの異なるソリューションについて説明します。
インメモリ分散キャッシュとは何ですか？
では、メモリ内分散キャッシュとは何であり、どのように高速でスケーラブルであり、場合によっては比較して信頼性が高いのでしょうか。 したがって、分散キャッシュは、複数の安価なキャッシュサーバーのクラスターであり、メモリ、CPU、およびネットワークリソースの論理容量に一緒にプールされます。 したがって、サーバーのチームがあり、それらのサーバーのチームがクラスターに結合されている場合、それはアプリケーションの論理的な容量ですが、サーバーまたはVMの物理的なセットであるため、私たちの背後には複数のリソースがあり、その場でサーバーを追加します。 したがって、安価なキャッシュサーバーが一緒になって一緒になり、リソースをプールします。これが分散キャッシュの基盤を形成します。
次に、キャッシュ更新をキャッシュサーバー間で同期しました。複数のサーバーがあり、複数のクライアントアプリケーションが接続しているため、データに関しては非常に一貫性があります。したがって、XNUMXつのキャッシュサーバーで行われた更新は、他のWebキャッシュサーバーで表示する必要があります。また、それに接続されているクライアントに対しても、可視という用語を使用しました。これは、一貫性がなければならないことを意味します。 ここではレプリケーションを用語として使用しませんでした。レプリケーションは別の概念です。 したがって、すべての更新は同期して、またはすべてのキャッシングサーバーに一貫した方法で適用されるため、すべてのクライアントアプリケーションのデータを同じように表示できます。
次に、トランザクション、メモリ容量、およびその他のリソースに対してスケールアウトする必要があります。 サーバーをさらに追加すると、容量が増えるだけです。10,000台のサーバーがあり、15,000台目のサーバーを導入する場合、以前は20,000台目のサーバーでXNUMX件のリクエストを処理していたため、XNUMX台のサーバーで容量がXNUMX倍になるとXNUMX件になります。 XNUMX秒あたりXNUMXのリクエストを処理する必要があり、それが私たちの経験です。 サーバーの数を追加すると、実際には容量が増加し、全体的な要求処理能力が増加します。これをサポートするためのベンチマーク数をいくつか示します。 これは、一般的な分散キャッシュのデプロイメントアーキテクチャです。
キャッシュサーバーのチームがあり、すべてのWindows環境が2008、2012でサポートされ、すべてのアプリケーションがクライアントサーバーモデルでそれに接続し、リレーショナルデータベースに加えてこの高速でスケーラブルで信頼性の高いソースを使用します。 いつの日か、これがリレーショナルデータベースに存在するようになり、データの一部またはすべてをキャッシュに取り込むことができます。 セッション状態これがメインストア、ビューステート、出力キャッシュになります。 SignalR backplane これがそのためのメインプロバイダーになります。
NCache パフォーマンスベンチマーク
非常にスケーラブルであることをサポートするためのベンチマーク数をいくつか示します。 当社のウェブサイトでは、これらの番号が公開されています。 したがって、これらはテストの詳細です。パフォーマンスを見ると、読み取りではこれが書き込みではそれほど直線的ではありませんが、これは今日のウェビナーで使用するトポロジであり、読み取りと書き込みは直線的に増加しています。読み取りと書き込みは直線的に増加し、バックアップも同様です。 したがって、これにはバックアップサポートも付属しているため、書き込みのパフォーマンスまたは容量は、パーティションにバックアップがない場合よりもわずかに少なくなります。したがって、これにもバックアップのオーバーヘッドがあります。 したがって、これは読み取りと書き込みで最も一般的なトポロジであり、サーバーを追加すると、実際には容量もスケールアウトされます。
ハンズオンデモ
デモ環境に移動し、分散キャッシュを設定してから、これらの機能をXNUMXつずつ使用していきましょう。ご不明な点がありましたら、どうぞよろしくお願いいたします。
使用します、すでにダウンロードしてインストールしました NCache、このウェビナーの範囲はありません NCache 構成またはセットアップ。 それで、ここでいくつかの詳細をスキップしますが、あなたに知らせるために、私は ダウンロード NCache 私たちのウェブサイトから完全に機能するトライアルを行い、それをXNUMXつのキャッシュサーバーボックスにインストールしました。私の側のXNUMX台のマシンをクライアントとして使用します。 インストールできます NCache クライアントでも、または必要に応じてNuGetパッケージを使用できます。
キャッシュを作成する
キャッシュを作成します。今日焦点を当てているのはaspnetcacheという名前です。
パーティションレプリカキャッシュを選択します。これらの設定はすべて、通常の NCache 建築 ウェビナー。
非同期レプリケーションオプションとここでは、最初にキャッシュクラスターの一部となるサーバーを指定します。
TCP/IPポートについてはすべて同じにしてください。 NCache はTCP/IPベースの通信であり、サーバーサーバー通信とクライアントサーバーはTCP / IPを介して管理され、各サーバーのキャッシュのサイズはすべてデフォルトのままで、エビクションをデフォルトのままにして、終了を選択します。
これは、キャッシュの設定がいかに簡単かです。 右側のペインには、このキャッシュに関連するすべての設定があります。ちなみに、コマンドラインやPowerShellツールを設定して、コマンドラインやPowerShellからすべてを管理することもできます。 アプリケーションを実行する予定の場所からmyboxを追加します。 これで、クライアント側の構成が更新され、このキャッシュに接続できるようになりました。このキャッシュクラスターを起動してテストします。これで完了です。 この時点で、サーバーサイトのセットアップは完了です。 皆さん、何か質問がありますか？ さて、これが始まりました。 右クリックして統計を選択します。
ロン、ここで質問があります。 NCache JSPセッション用のJavaアプリケーションをサポートするためのフローセッションキャッシングですか、それともASP.NETアプリのみですか？ これは非常に良い質問です。主にこのウェビナーはASP.NETに焦点を当てていたので、ASP.NETサイトに焦点を当てましたが、この質問に答えるためにはい NCache Javaアプリケーションを完全にサポートします。Javaクライアントがあります。Javaアプリケーションの場合、Java WebセッションまたはJSPセッションがある場合は、非常によく使用できます。 NCache。 したがって、プロバイダーはまったく同じであり、コード変更オプションはなく、サンプルアプリケーションがインストールされています。 NCache 同じように。 だから、あなたはただインストールする必要があります NCache Windows環境で、またはコンテナを使用して、アプリケーションをWindowsで実行することも、Linux UNIX環境で実行することもでき、Javaアプリケーションを完全にサポートします。
キャッシュ統計の監視
いくつかの監視の側面を確認するためだけに統計を開きました。にインストールされている監視ツールも開きました。 NCache。 ストレステストツールアプリケーションをすばやく実行して、キャッシュが正常に構成されていることを確認します。次に、実際にサンプルアプリケーションを開始し、XNUMXつのクライアントが接続されているので、ここにアクティビティが表示されます。カウンターがあります。両方のサーバーからのXNUMX秒あたりのリクエスト数を示しており、すでにいくつかのグラフが入力されています。
したがって、すべてが適切に構成されていることを確認してから、サンプルアプリケーションを開始できます。
したがって、最初のサンプルアプリケーションは、これらはXNUMXつの異なる最適化です。 これらについてXNUMXつずつ説明してから、サンプルアプリケーションを紹介します。 まず第一に、あなたは使用することができます NCache データキャッシングについては、データベースのボトルネックに関する詳細なAPIがあります。 高速なメモリ内分散キャッシュを使用できます。メモリ内にあるため高速であり、サーバーを追加できるためスケーラブルであり、サーバーを追加することで実行時に容量を増やすことができます。 これはコード変更なしのオプションであり、セッションは非常に信頼性が高く、セッション状態に使用できます。 NCache これらは複製されるため、セッションは比較して高速でスケーラブルなリポジトリでも管理され、スティッキーなセッション負荷分散は必要ありません。 これらのサンプルアプリケーションを実際に示したら、さらに多くのメリットについて説明しますが、これらがメリットの一部であることをお知らせします。 NCache プラグを差し込むとすぐに NCache これらのために。
Webファームの場合、ビューステートを使用でき、サーバー側にビューステートを保存できます。ビューステートを送信する必要はなく、ビューステートのペイロードサイズも削減されます。その後、次を使用できます。 NCache for SignalR Backplane、それは私たちのXNUMX番目のオプションであり、次に使用することもできます NCache 静的コンテンツの出力キャッシュにも当てはまります。これはASPにも当てはまります。.NET core。 ASP内のセッション状態に使用できます.NET core ASPでの応答キャッシュにも使用できます.NET core 分野の様々なアプリケーションで使用されています。
ASP.NETセッションキャッシングサンプル
それでは、ASP.NETセッション状態ストレージから始めましょう。 これはすべての中で最も簡単です。これはXNUMX分以内に設定でき、すばやくテストできます。 実際のところ、私はそれをセットアップする方法をあなたに示して、それからそれを始めるつもりです。
これが私たちの最初のサンプルアプリケーションです。私が行ったことは、これがインストールされていることです。 NCache 同様に、私はそれを少し変更しました。 セッションキャッシングの場合、必要なのはアセンブリタグを追加することだけです。これらのXNUMXつのアセンブリは冗長です。これらはオブジェクトキャッシングの別のユースケース用ですが、必要なのは Alachisoft.NCache.SessionStoreProviderアセンブリ。 バージョン4.9は最新バージョンであるため、このアセンブリにもカルチャとパブリックトークンが必要です。 したがって、これはこのセッション状態アセンブリへの一般的な参照です。この後、既存のセッション状態タグを次のように置き換える必要があります。 NCache。 すでにセッション状態タグを持っている場合はそれを置き換える必要があります。持っていない場合はInProcでした。その場合は実際に置き換えることができ、これを新しいものとして追加できます。 ここで、モードはカスタムで、プロバイダーは NCacheSessionsProvider、タイムアウト値は、セッションオブジェクトが NCache XNUMX分以上アイドル状態が続くと、キャッシュから自動的に期限切れになります。
次に、有効にする例外などのいくつかの設定があります。 したがって、これはサンプルタグとして使用できます。ここからコピーしてアプリケーションに貼り付けることができます。次に、最も重要なのはキャッシュ名です。キャッシュ名aspnetcacheを指定するだけです。 同じ名前のaspnetcacheを使用していると思います。名前を指定するだけなので、このサンプルの構成は解決されます。 したがって、client.ncconf aspnetcacheからこのキャッシュの構成を読み取るか、このファイルをプロジェクトの一部にすることもできます。 NuGetパッケージを使用している場合は、実際にこのファイルをプロジェクトの一部にすることもできます。それだけです。 ここではXNUMXつのページを使用していたので、これを保存してメインページとして作成します。これを実行すると、プロバイダーのゲストゲームセッションが起動し、に接続されます。 NCache セッションデータ用。
したがって、キャッシュにセッションオブジェクトを作成することを期待しています。次に、セッションからデータを読み取り、作成されているセッションオブジェクトも表示します。 これは推測ゲームアプリケーションであり、0から23までの数字を推測し、セッションオブジェクトから前のゲストを実際に出力することができます。 つまり、数値は12から12の間であると推測しました。したがって、23と推測します。数値は、13から23の間です。したがって、最後の数値も読み取ります。 数がXNUMXからXNUMXの間であると推測しましょう。それでは、もう一度推測しましょう。 推測することはできません。うまくいけばそこにたどり着きますが、サーバー側でセッションオブジェクトが作成されている必要があることをお知らせします。
ツールを使ってこれをお見せしましょう。 NCache testは、このサンプルアプリケーションに追加するキーワードです。 これを変更すると、異なるアプリケーションのセッションを区別するために、XNUMXつのアプリケーションがあり、両方のアプリケーションに同じキャッシュを使用するシナリオが発生する可能性があります。 したがって、その場合、セッション変数にアプリIDを追加できますが、通常、XNUMXつのアプリケーションがそのセッションを専用キャッシュにキャッシュする必要があります。 したがって、空の文字列として指定しても問題ありませんが、これは作成されており、これはASP.NETセッションIDであり、ここのセッションはここに複製されます。 したがって、このサーバーがダウンした場合、セッションデータが自動的に利用可能になります。
のいくつかのより多くの利点 NCache InProcヒットと比較したセッション状態はアウトプロセスであるため、Webプロセスは完全にステートレスです。 つまり、これはHTTPプロトコルで好まれており、よりスケーラブルで、より多くのリソースを追加できます。メモリ内にあるため高速であり、InProcと比較して同等であり、非常に信頼性があります。 サーバーがダウンした場合でも、何も心配する必要はありません。最も重要なことは、スティッキーセッションやバランシングを使用する必要がないことです。 負荷分散を均等にすることができ、リクエストはXNUMXつのWebサーバーから別のWebサーバーにバウンスできます。 Webサーバーは何も保存しておらず、実際のセッションオブジェクトはに保存されているため、何も心配する必要はありません。 NCache これは、アプリケーションとStateServerの比較のための外部プロセスストアです。 これは単一障害点ではありません。サーバーがダウンしたり、メンテナンスのためにサーバーをダウンさせたりしても、何も心配する必要はありません。問題なく動作します。
第二に、それは非常にスケーラブルであり、その場でサーバーを追加することができます。 非常に信頼性が高く、非常にスケーラブルで、比較すると高速です。 データベースの場合、低速ではなく、高速で、非常にスケーラブルであり、データベースのレプリケーションがない場合は、信頼性の点でさらに優れている場合があります。 だから、これはそれと内のもう一つの重要な機能をカバーしています NCache マルチサイトセッションのサポートです。これはもうXNUMXつの機能です。 マルチリージョンセッション、XNUMXつの異なるリージョンからのセッションを保存する場所 NCache 完全に同期されたセッションを持つことができます。
セッション要求がXNUMXつのサーバーから別のサーバーに、またはXNUMXつのリージョンから別のリージョンにバウンスする場合、セッションはリージョン全体に自動的にフィードされ、ここに移動します。その逆も同様です。 したがって、サイドダウンする必要がある場合は、キャッシュを一定期間実行し続けることで、すべてのトラフィックを反対側にルーティングできます。 だから、それは別の機能です。 私たちの主要な航空会社のXNUMXつである航空会社の顧客は、実際にこの機能をロケーションアフィニティに使用しています。 したがって、これはASP.NETセッションの状態をカバーします。 これはコード変更なしのプロバイダーです。質問がある場合はお知らせください。JSPセッションに関する質問にはすでに回答済みです。次を使用できます。 NCache JavaベースのWebセッションの場合も同様です。 質問がないと仮定します。
ASP.NET View State キャッシングサンプル
次に、ビューステートについて説明します。 NCache ビューステートプロバイダーもあります。その仕組みは、基本的にサーバー側でビューステートを保持することです。 これもプロバイダーです。必要なのは、セクショングループを正しく設定すること、コンテンツ設定、ContentOptimization.Configurations.ContentSettingsです。 セクショングループの名前はnContentOptimizationで、これにはキャッシュ名を使用する設定がいくつかあります。たとえば、現在mycacheを使用しています。これは、私たちが設計した方法です。 ASP.NET view state プロバイダーは、サーバー側のビューステートを正しく保持することです。 したがって、最初に、以前のプロバイダーをプラグインしているにもかかわらず、キャッシュなしで実行しますが、ビューステートキャッシングをfalseに設定し、これを実行して、実際のビューステートが戻ってくることを示しますブラウザに。
それで、私はあなたにデフォルトのオプションを示し、それから私はあなたに NCache 状態を表示し、違いを比較します。 それで、いくつかのページのWebファームがあり、ビューページのソースを示します。
これはデフォルトのビューステートである値の部分です。ここに持ってきて、ここに一時的なドキュメントを作成します。 これがデフォルトのビューステートであり、応答パケットの一部であり、このページに戻ると、要求パケットの一部にもなります。 これは個別のリクエストであり、文字数に注意してください。リクエストとレスポンスのヘッダーに正しく追加されています。これは、これから行うすべてのリクエストで同じです。 もう少しリクエストを表示し、このリクエストのビューページソースも表示します。
つまり、画面に表示されるものとほぼ同じです。 今と NCache 私たちが行ったことは、ビューステートプロバイダーの助けを借りて、ビューステートをインターセプトすることです。 サーバー側でビューステートを保持するため、この値の部分でWebファームの特定のページのキーと値を作成し、サーバー側に保存しました。これでサーバー側に保存されるため、小さなトークンを送信します。ブラウザに戻ります。 つまり、これは静的サイズトークンであり、ブラウザに返送されます。 それは実際には決して変化しません、それは常にそこに送られ、そして再び使用されるために戻されます、そしてあなたがポストバックするとき、あなたは実際にに電話をかけます NCache から追加のビューステートをフェッチします NCache 次に、それをWebファームで使用して、実際に状態を表示します。これは、舞台裏で行っていることです。
ビューステートパケットを取得する利点は、トークンであるため、サイズが小さくなります。 したがって、これは、要求と応答のペイロードのサイズを削減するという全体的な影響があります。 したがって、これによりパフォーマンスが向上します。次に、数百キロバイトのビューステートが数千のリクエストに対して前後に移動する場合、帯域幅が消費されます。 S、これは起こりません NCache, NCache ビューステートは静的トークンであり、トークンを簡単に紹介します。
ロン、質問に飛び込んでみよう、本当に速い NCache セッションの暗号化やビューステートキャッシングなどの請求書セキュリティ機能はありますか？ はい、そうです。これらは明示的に設定できる機能であり、一般的なものです。 NCache 特徴。 したがって、すべてのビューステートはすでに暗号化された文字列ですが、さらに暗号化して、それが周りにあるかどうかを確認したい場合は、キャッシュ自体で暗号化を有効にして、それを停止し、暗号化を設定できます。DESプロバイダーがあります、AESプロバイダー、FIPSクライアント、FIPS準拠、DESAESプロバイダーがあります。 したがって、はい、これを設定するだけで、クライアントサーバーからのすべてのペイロードがここで暗号化および復号化され、それぞれフェッチされます。 ですから、これはオンデマンドで設定でき、物事を進めることができるものです。この質問によって、私もそれを強調したいと思います。 NCache これは保存されていません後のビューステートです NCache プラグインされていますプロバイダーとしてプラグインされており、違いに気づきました。これは、これらの多くの文字とこれらの多くの文字です。 だから、これはあなたのデフォルトです、これは NCache そして、これが遅くなり、すべてのパフォーマンスの向上にわたってペイロードのサイズが減少し、帯域仮想化のコストが下がるという違いを自分で確認してください。 そのため、アーキテクチャに多くの改善が見られます。最も重要なのは、実際のビューステートが実際にブラウザに返されることはもうないということです。 サーバー側に保存されます。一般的に安全です。
だから、この質問に基づいてこれを尋ねてくれてありがとう NCache ビューステートは、実際に必要なサーバー側に保存されるため、デフォルトではデフォルトオプションよりも安全です。 だから、それがお役に立てば幸いです。 これを閉じます。ビューステートに関する質問があれば、それ以外の場合は次のセグメントに進みます。
アプリケーションデータキャッシングサンプル
時間の制約があるため、最初にオブジェクトのキャッシュを紹介します。 私はこれを最初にカバーする必要があると思います。 データベースのボトルネックの場合、データベースに保存されて速度が低下するものはすべて、次のような分散キャッシュを使用できます。 NCache。 これは NCache ここにAPIがあります。
キャッシュ接続Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();
Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");これは、キャッシュを接続する方法です。これは、操作を行う最後の方にハンドルを配置する方法です。すべてがキーと値のペアに格納されます。これは、データテーブルをドメインオブジェクトにマップできる文字列キー値.NET許可オブジェクトです。次に、ドメインオブジェクトを保存し、関係を持つ個々のオブジェクトまたはコレクションを保存することでドメインオブジェクトを処理します。SQLはリストを検索しますが、これは基本的な作成、読み取り、更新、削除の操作です。
サンプルアプリケーションをすばやく実行し、実際にどのように使用するかを示します NCache オブジェクトキャッシング用。 これらのXNUMXつの要約参照が必要です Alachisoft.NCache.Webおよび Alachisoft.NCache。ランタイム。 これが終わったら、これをスタートアップページとして作成し、その背後にあるコードを示します。 これはASP.NETWebファームですが、コントローラーMVCがある場合は、同じアプローチを使用することもできます。この名前空間がここにあり、このアプリケーション内でmycacheを初期化しています。キャッシュの名前を指定する必要があり、 InitParams右キャッシュInitParamsを使用して、ここでサーバーを指定することもできます。または、名前を指定して、前に示したclient.ncconfを介して名前を解決することもできます。 顧客を追加するaddObjectがあります。名前はDavidJones、男性、連絡先番号です。これはアドレスで、cache.Addと呼んでいます。
同様に、ページを変更してこれを挿入するか、実際に名前も変更して、これが更新されていることを確認してから、cache.Insertを呼び出してから、オブジェクトを取得して、オブジェクトの数。 そのオブジェクトを削除しています。負荷テストを実行しているだけです。 100アイテムが何度も更新されます。 それでは、サンプルアプリケーションを実行してみましょう。これは、アプリケーションを開始するのがいかに直感的であり、アプリケーションを起動するだけで、これらすべての操作を実行できるようになります。実際にこれを行う前に、キャッシュされたビューステートを表示します NCache.
23ページのビューステートのキーを確認できます。これはオブジェクトの実際のキーであり、実際のビューステータスは値の部分にあります。 内容をクリアしただけだと思って、今は言及し忘れました。 したがって、現在はオブジェクトキャッシュデータのみを扱っているので、実際にはマネージャーからこれを実行させてください。便利です。 それで、私はオブジェクトを追加します、顧客は私がこのオブジェクトを取り戻すと追加しました。 つまり、2歳のDavid Jonesがいます。更新してから追加し、David Jones 50に戻します。その後、1歳になり、キャッシュ0のアイテムを削除します。このオブジェクトは再びキャッシュXNUMXにアイテムを挿入し、挿入は追加され、オブジェクトを元に戻します。これをキャッシュに表示できます。 したがって、この時点でXNUMXつのオブジェクトを処理していて、キーはそれに追加された顧客の名前の顧客でした。次に、ロードを開始し、今すぐテストします。 キャッシュにいくつかのアクティビティが表示され、リクエストが着信し、データを処理するクライアントリクエストがあります。
そして、このダンプキャッシュキーをもう一度実行すると、XNUMX個のキーが一緒にダンプされたことが表示されます。 だから、これらは私が追加したキーです。 したがって、これは、オブジェクトキャッシング、データベースに属し、処理速度を低下させるデータを開始するのがいかに簡単であるかを示し、拡張性を制限します。 NCache オブジェクトキャッシングを使用します。 ドメインオブジェクト、コレクション、データセット、画像など、あらゆる種類のアプリケーション関連データをオブジェクトキャッシュモデルを使用してキャッシュできます。 これがお役に立てば幸いです。これから始めましょう。これで、次にデータキャッシングがカバーされます。 SignalR Backplane.
ASP.NET SignalR Backplane サンプル
話しましょう SignalR NCache 私たちは強力です pub/subメッセージング プラットホーム。 サンプルアプリケーションがあります。これからNuGetパッケージも紹介します。 NCache ライブラリはインストール時にインストールされます。または、NuGetパッケージを使用することもできます。 したがって、オンラインのNuGetリポジトリにアクセスして、 NCache、すべてのNuGetパッケージが表示されます。 Alachisoft.NCache.SDKはオブジェクトキャッシング用、Linqはlinqクエリ用、セッション状態プロバイダーがあり、オープンソースとコミュニティもあります。
これは、このアプリケーションに含まれているNuGetパッケージです。 それをビルドして、NuGetパッケージを追加する必要があるため、正常に機能するかどうかを確認しましょう。 大丈夫、 SignalR Backplane あなたがする必要があるのは、SignalR NuGetパッケージが追加されていることを確認することだけです。つまり、まだインストールされていない場合は、これがインストールされます。 したがって、NuGetパッケージを追加し、その後追加する必要があります。必要に応じていくつかのSignalRアセンブリを追加し、いくつかのヘルプアセンブリも追加しました。その後、web.configに移動すると、そこにいくつかの設定を追加しました。キャッシュのmynameはaspnetcacherightで、次にイベントキーです。これは、このために好きなトピックの名前です。 したがって、実際には、この特定のチャットアプリケーションのSignalRチャットメッセージまたはSignalRメッセージを送信するためのトピック名を指定する必要があります。その後、指定する場所でXNUMX行のコードを変更するだけです。キャッシュの名前とイベントキーおよびポイントtowords NCache サンプルアプリケーションを実行します。 自動的に使用します NCache SignalRバックプランの場合、 NCache プラグインするのがいかに簡単かというあなたのバックプランになります NCache SignalRアプリケーション用。
ネイティブの.NETとは異なり、得られるメリット Redis データベースやメッセージバスと比較して、高速でスケーラブルで信頼性が高く、完全に機能する完全にサポートされたpub / subモデルがあり、これをバックアップしています。 したがって、pub / subメッセージングを直接使用することもできますが、pub/subメッセージングのそのXNUMXつのユースケースのXNUMXつの拡張は SignalR Backplane セットアップも非常に簡単です。
それで、このアプリケーションが起動しました。 ここに鍵があるはずです。鍵を見つけるのは難しいと思いますが、チャットを紹介するだけです。 NCache、これは機能します。別のユーザー、たとえばNickに署名して、これを別のブラウザーに送信します。 これを戻すと、接続されている他のクライアントにも実際にメッセージがブロードキャストされていることがわかります。 だから、それはそれがどれほど簡単かです。 もう一度質問して、期待どおりに機能しているかどうかを確認します。 だから、これは推進されています NCache 設定は非常に簡単です。これが、設定方法と最後の機能です。 NCache、XNUMX番目のブースターは出力キャッシングです。
ロン、SignalRについて質問があります。SignalRメッセージは、内のビジュアルオブジェクトとして保存されます。 NCache またはします NCache これに通知を使用しますか？ NCache これにはpub/sub通知を使用します。 つまり、バックグラウンドにあるpub / subメッセージングプラットフォームがあります。キャッシュ自体には、XNUMXつのオブジェクトだけが表示されるか、トピックであるためオブジェクトも表示されません。 つまり、作成されるトピックがあります。それは、複数のワークプロセスが接続され、実際にブロードキャストされる論理トンネルです。 NCache、そのトピックへのすべてのSignalRメッセージ。 つまり、キャッシュに追加されたメッセージがたくさん表示される場合は、通知フレームワークです。表示されない場合は、トピックがXNUMXつだけ表示され、トピック内にメッセージが表示されます。 ポッパーエンカウンターにはいくつかの統計があり、トピック内にメッセージがいくつあるかを視覚化できますが、個々のオブジェクトに関する限り、それらのオブジェクトは表示されず、XNUMXつのオブジェクトのみがトピックとして表示されます。 それがお役に立てば幸いです。
ASP.NET出力キャッシングサンプル
この中の最後の機能ですが、私たちも時間に余裕がないと思います。これについてはすぐに説明します。 これは、出力キャッシングセクションを設定するために必要な出力キャッシングです。以下を参照する必要があります。 NCache キャッシュプロバイダーdllを出力します。 これはここにあります、あなたはこれらの参照が必要です Ncache.Adapters、web、runtime in cache、その後はN出力キャッシュプロバイダーを参照し、キャッシュの名前をaspnetcacheに設定します。バージョンは最新である必要があります。 それが機能する方法は、静的ページの出力を実際にキャッシュし、それを実行するだけで、静的ページの出力をキャッシュするだけです。 静的なのがページ全体またはページ内の一部であり、静的ページの一部をこのディレクティブ出力キャッシュで装飾する場合は、期間、場所、およびVaryByParamを指定します。 これらのパラメータが変更されていない場合、それは自動的にこれが同じ出力であることを意味します。
したがって、キャッシュされた出力はエンドユーザーに表示され、ページを実行する必要はありません。データベースを使用する必要もありません。ワーカープロセスの負荷を軽減し、データベースを削除し、高価なCPUとマシンリソースを節約します。エンドクライアントが利用できる既製のページ出力を取得します。 したがって、全体的にパフォーマンスが向上します。ASP.NETはこれを機能として提供し、 NCache 非常にスケーラブルで、非常に高速で、非常に信頼性の高いページ出力が格納されている分散レベルになります NCache コードを変更せずに、これはASPにも当てはまります.NET core 同様に、あなたが使用できる方法で使用することができます NCache ASP内.NET core Webアプリケーションも同様です。 その上で別のウェビナーを行いました。分散キャッシュがある場合は、セッションストレージがあり、次にASPもあります。.NET core 応答キャッシングとEFコアキャッシング。
これらは私が強調したかった機能の一部です。これでXNUMXつのパフォーマンスブースターが完成しました。 よろしくお願いします。他にご不明な点がございましたら、お気軽にお問い合わせください。時間も非常に短いと思います。 それで、他に何か質問があれば、今がそれらの質問をする時ですので、私に知らせてください。
一般的に、私も言及したいと思います NCache 完全に弾力性のあるXNUMX％の稼働時間の動的キャッシュクラスターであり、単一障害点はありません。 暗号化、セキュリティ、圧縮、電子メールアラート、データベース同期、SQLのような検索、連続クエリ、pub / subモデル、リレーショナルデータなどの多くのトポロジと機能があります。 NCache、これらはすべて、さまざまな機能の一部としてカバーされています。 したがって、これらに関する具体的な質問がある場合は、それらの質問もお気軽に質問してください。それ以外の場合は、結論を出してニックに渡します。
ロンさん、ありがとうございました。最後の質問ですが、セッションキャッシング用のカスタムプロバイダーを設定することは可能です。 NCache? NCache すでにカスタムプロバイダーです。 NCache カスタムプロバイダーの下にあり、デフォルトのモードはInProc、State Server、またはSQL Serverであり、ASP.NETのXNUMX番目のモードはカスタムです。 それで、 NCache プロバイダー自体はカスタムプロバイダーです。 これに関する特定の要件がある場合は、質問について少し混乱しています。それ以外の場合はお知らせください NCache それ自体はASP.NETのカスタムプロバイダーです。
ロン、ありがとうございました。質問がない場合は、本日はご参加いただきありがとうございました。また、ロンに貴重な洞察をありがとうございました。ご不明な点がございましたら、メールでお問い合わせください。で support@alachisoft.com。 あなたは私たちに電子メールをドロップすることによって私たちの営業チームに連絡することができます sales@alachisoft.com 営業チームの誰かが喜んであなたと協力し、すべての質問に確実に答え、必要なすべての情報を提供します。また、当社のWebサイトから試用版をダウンロードすることをお勧めします。 NCache、30 日間の試用版が付属しています。 また、有料サポート オプションと無料のオープン ソース エディションを備えたメディエーションもあります。 ご参加いただきありがとうございました。また次回お会いしましょう。