最適化するXNUMXつの方法 NCache 性能

録画されたウェビナー
KalAliとSamAwanによる

NCache は、.NET 用の人気のあるオープンソースのメモリ内分散キャッシュです。 アプリケーション データをキャッシュし、高価なデータベース トリップを削減することで、.NET アプリケーションを拡張するのに役立ちます。 NCache キャッシュ層クラスターにさらに多くのキャッシュ サーバーを追加できるようにすることで、線形に拡張します。

最適化する方法を学ぶ NCache 適切に構成し、パフォーマンスを向上させる機能を使用することにより、パフォーマンスを向上させます。

このウェビナーの内容は次のとおりです。

• はじめに NCache とそのアーキテクチャ
• 一般的な方法 NCache 使用されている
• NCache パフォーマンス向上機能
• NCache パフォーマンス向上の構成オプション

概要

今日は、改善のための XNUMX つのトリックに関するウェビナーを開催します。 NCache パフォーマンス。 このウェビナーのモードは視聴のみです。 あらゆる種類の質問をすることができます。 右側のペインに質問と回答のタブがあります。 ご質問を入力していただければ、当社のいずれかがその質問にお答えいたします。 ウェビナー中に質問や懸念がある場合、または私たちの声が聞こえない場合は、チャット ウィンドウを使用してください。 カルはプレゼンテーションの技術的な部分をすべて話すつもりです。 あまり技術的または販売に関連しないことがあれば、私に直接質問してください。 そうは言っても、私はそれを Kal に渡し、彼がプレゼンテーションを開始するつもりです。

よし。 ありがとうサム。 共有を開始したばかりなので、私の画面が表示されることを確認してもらえますか? はい、画面はまったく問題なく見えます。 よし、完璧だ。 さて、皆さん、先ほどサムから紹介されました。私の名前はカルです。今日のウェビナーのテーマは「最適化する XNUMX つの方法」です。 NCache パフォーマンス。

したがって、今日のウェビナーでは、以下に関する一般的な詳細について説明します。 NCache また、パフォーマンスを最適化するためにアプリケーション内でどの機能を使用できるかについても説明します。 それで、 NCache すでにパフォーマンス ソリューションになっています。 データベースへのアクセスが減るため、アプリケーションのパフォーマンスが迅速に向上します。 しかし、これらの機能を使用すると、実際にはそれをさらに改善することができ、これらの XNUMX つのトリックは実際にユースケースに基づいたものになります。 それぞれのユースケースを並べて紹介します。これに基づいて、特定のシナリオに適用されるものに基づいて、これを使用して、これがどのように機能するかを確認することができます。 そこで、さまざまなアプリケーションの実際の実践的なデモをいくつか取り上げ、それに従って、さまざまな状況でどのように動作するかを見ていきます。 NCache 仕組みと、これらの機能が実際にどのように役立つのかを説明します。 それでは、これからプレゼンテーションを進めさせていただきます。

スケーラビリティの問題

そこで、まず最初に、ほとんどの展開シナリオで見られるスケーラビリティの問題について実際に説明しましょう。 したがって、通常は Web ファームがあり、それは ロードバランサ この種の層では、このシナリオは通常、非常にスケーラブルです。 アプリケーションにさらに多くの負荷がかかっていることがわかると、基本的にはこの層にサーバーを追加するだけで済みます。そうすることで、環境が受け入れることのできる合計負荷の観点から、環境の容量が実際に増加することになります。たとえば、XNUMX 秒間に受信できるリクエストの総数です。

実際の問題、実際のボトルネックは、これらのアプリケーションがバックエンド データ ソースと通信する必要がある場所にあります。 おそらく、参照データを取得するため、またはそこに保存されている他の種類のデータを取得するためです。 つまり、基本的にそこがボトルネックになります。 通常、バックエンド データ ソースはデータベースです。 ご存知のとおり、データベースはストレージとしては優れていますが、問題は、ディスク上にあるために一般的に遅いという点にあります。 トランザクション負荷が高くなると停止する傾向があり、スケーラビリティもあまり高くありません。

ソリューション

したがって、このようなシナリオでは、企業/組織は次のような方向に進む傾向があります。 NoSQL database, しかし、それは現時点では最適なアプローチではありません。 なぜなら、相互に互換性を持たせるには、アプリケーション内だけでなく実際のデータ内でもアーキテクチャ全体を変更する必要があるからです。 したがって、このようなシナリオでは、最適なアプローチは、次のようなメモリ内分散キャッシュになります。 NCacheこれは、すべてがメモリ内に配置されるため、より高速でスケーラブルです。 したがって、これをデータベースと比較すると、その場合はディスク上に存在していました。 これで、メモリ内に存在するすべての情報が得られました。 分散キャッシュは論理的には単一のユニットですが、その下にこのクラスター化されたキャッシュをホストする複数の独立したサーバーがあるため、よりスケーラビリティが高くなります。

これは非常にスケーラブルなトポロジです。 ここではサーバーを必要な数だけ追加できます。 ご存知のとおり、これは基本的に、これらすべてのサーバーのメモリ リソースだけでなく、これらすべてのリソースの計算能力もプールします。 したがって、サーバーの数を追加すると、保存できる総データ量という点でキャッシュの容量が増加します。 実行される可能性のある合計操作または合計負荷も同様です。

したがって、Web ファームにさらに多くの負荷がかかっていることがわかった場合は、実際にキャッシュ クラスター上のサーバーの数も増やすことができ、実際にこの層も拡張可能になります。 これで、キャッシュ層が Web ファームから受信するリクエストに一致するようになりました。 したがって、データベースに存在していたスケーラビリティ以外の部分を削除するのに実際に役立ちます。 これの最も良い点は、データベースの代替ではないことです。 合わせてお使いいただけます。 つまり、基本的にキャッシュ クラスターはアプリケーションとデータベースの間に配置されます。 直接電話をかけることもできます。 しかし、それが行うことは、あなたが作ることができるということです NCache データの唯一のソースであり、それを使用して、このキャッシュで提供されるデータ アクセス レイヤー機能を使用して、キャッシュは実際にバックエンド データ ソースにデータを書き込んだり、バックエンドからデータを取得したりできます。データソース。

したがって、これを使用すると、キャッシュはバックエンド データ ソースと同期したままになります。 つまり、メモリ内に存在し、よりスケーラブルなソースであるため、より高速なソースから最新のデータを入手できます。 したがって、この場合は非常に良いトレードオフになります。

NCache 展開

それでは、について話しましょう NCache この図の展開。 ご覧のとおり、これらは基本的に、アプリケーションをホストするアプリケーション サーバーまたは Web サーバーです。 通常、それらはロードバランサーの背後にあります。 以前はデータベースなどのバックエンド データ ソースを直接呼び出していましたが、現在はここにキャッシュ層が存在します。 これは、クラスター化されたキャッシュをホストする専用のキャッシュ層があるという推奨展開です。

つまり、アプリケーションが行っていることは、 NCache データの唯一のソース。 データの取得や何らかの処理を求めるすべてのリクエストはキャッシュ上で直接行われ、キャッシュにデータがない場合は、データ アクセス層プロバイダーを使用して実際にデータ ソースからデータを取得できます。 つまり、これがあなたの環境内で行われていることです。 これらのサーバーは、前に述べたように、専用サーバーであることが推奨されており、非常に安価なサーバーです。 唯一の前提条件は、 NCache この場合は単に .NET framework。 クラスター キャッシュをホストしているこれらのサーバーには、クラスター キャッシュをホストする機能を持つキャッシュ サーバー インストールがあり、クライアントでは、ここにあるクライアント ボックス (アプリケーション サーバー) には、 remote client これはローカル キャッシュをホストでき、実際にリモートのクラスター化キャッシュへの接続に役立ちます。

ということで、展開はこんな感じです。 これらはすべて線形にスケーラブルです。 サーバーの数を追加すると、キャッシュの総容量が増加します。

のXNUMXつの一般的な使用法 NCache

の XNUMX つの一般的な用途について話しましょう NCache。 私がこれらすべてのことを急いで検討しているのは、これら XNUMX つの方法を確認し、その詳細を確認したいためです。そのため、何か質問があれば確実に答えることができます。 それでは、次の XNUMX つの一般的な使用法について説明しましょう。 NCache.

1. アプリケーションデータのキャッシュ

   XNUMX つ目はアプリケーション データ キャッシュです。 このスライドでは、次の XNUMX つの一般的な使用法について説明しました。 NCache。 したがって、最初の XNUMX つはアプリケーション データのキャッシュです。 この場合、基本的に行うことは、 NCache アプリケーション内で API を使用し、その API を使用すると、アイテムを追加したり、キャッシュからアイテムを取得したり、必要な方法でキャッシュ上でさまざまな操作を実行したりできます。 だから何 NCache ホストの機能はありますか。基本的に、その中にあるものはすべてキャッシュできます NCache。 画像、カスタム オブジェクト、ドメイン オブジェクト、コレクションなど、基本的には何でもかまいません。 したがって、.NET で許可されているものはすべてキャッシュ内にキャッシュできます。 NCache を導入してアプリケーションを使用します。 NCache API は非常に使いやすく、実際にキャッシュ上でさまざまな操作を実行したり、アイテムを実際に追加したりフェッチしたりできます。

2. ASP.NET、ASP.NET Core キャッシング

   次の使用例は、ASP.NET、ASP に関するものです。.NET Core キャッシング。 したがって、その最初のものは、次のように使用できます NCache セッション状態プロバイダーとして。 シングルサイトでもマルチサイトでも構いません。 次にできるのは、 NCache ビューステートを保存します。 これは MVC 以前のものです。 その後、ビューステートの概念は存在しなくなりました。 その後、ASP.NET の場合は出力キャッシュ プロバイダーが必要になります。 NCache それとして機能し、その後 ASP として機能することができます.NET Core アプリケーションでは、コア レスポンス キャッシュにすることができます。 それで、あなたはそれを行うことができます NCache. NCache としても機能することができます SignalR Backplane。 したがって、番号 2 で説明したこれらのオプションはすべて、実際にはコード変更のないオプションです。 コードを変更する必要はありません。 基本的には、アプリケーションの構成ファイルを更新し、実際に使用できるものを使用するだけです。 NCache 保管したいものを何でも保管できます。 それはセッションである可能性があり、ビュー ステートである可能性があり、出力、さらにはコア レスポンス キャッシュである可能性があります。 したがって、これを使用すると、次のことができます NCache それらのものを保管します。 したがって、この場合も基本的にはコード変更オプションがなく、非常に使いやすいです。 いくつかの手順が必要です。 完全なドキュメントがあります。 サンプルも用意されており、その手順とドキュメントに従えば、サンプルであっても 15 分以内にセットアップできます。 すべてをセットアップできます。 実際にテストしてみて、どのように機能するかを確認してください。

3. イベントを通じたPub/Subおよびランタイムデータ共有

   次は Pub / Sub & イベントを通じた実行時データの共有。 つまり、基本的にこのケースでは、サーバーレス アプリがあり、それらの間で特定のメッセージや特定のデータを渡すために、ある種の同期が行われていることを確認したいとします。 NCache それだけの媒体として使えます。 パブリッシャーやサブスクライバーがいて、彼らがメッセージを公開することもできます。 これらに登録されているサブスクライバー、たとえばクライアントは、実際にそれらを取得して、そこからデータを取得できます。 NCache その場合は。

   したがって、典型的な例はグループ チャット アプリケーションです。 グループのメンバーがいて、全員が同じキャッシュに接続しており、実際にはグループ チャットに参加している可能性があります。 メンバーの XNUMX 人が何らかのメッセージを投稿すると、そのグループの他のメンバー全員がそのデータが追加されたという通知を受け取ります。 したがって、これは単なる基本的な例であり、さらに駆動型通知や継続的なクエリもあります。

以上が、 NCache 実際に提供しているものと、基本的にほとんどのお客様が使用しているものです。

NCache アーキテクチャ

実際に話してみましょう NCache 今は建築。 それがどのように機能するかを説明しましょう? だから基本的に NCache は 100% ピアツーピア アーキテクチャです。 単一障害点はなく、マスター スレーブや多数決などの類似の概念もありません。 NCache。 サーバーはその場で追加および削除できます。 キャッシュを停止する必要はなく、引き続き正常に動作します。 たとえサーバーの XNUMX つがダウンした場合でも、基本的には予期せぬシナリオで、クラスタ全体がダウンすることはありません。 サーバー間で回復ロジックが開始され、 redisそのデータをトリビュートするか、バックアップの XNUMX つからデータを取得すると、クライアント側で、クライアントは実際にクラスター内に存在する残りのサーバーに接続をフェイルオーバーします。

したがって、これを使用すると、実際にはデータは失われず、クライアントの接続は実際には他のサーバーにフェイルオーバーされます。 したがって、サーバーの XNUMX つがダウンした場合でも、リクエストは継続して行われます。 したがって、XNUMX 台のサーバーが稼働している限り、リクエストは処理されます。

したがって、これらすべての変更、サーバーの追加、予期せぬシナリオに備えたオンザフライでの削除などの構成変更はすべて、実際にクラスター全体に伝播されます。 したがって、これらすべての構成は実際には動的です。 クラスター内および構成に関する更新はすべて、クラスター内に存在するすべてのサーバーにマッピングされ、クライアントも自動的にそれを認識します。

NCache システム要件

キャッシュサーバー

それについて話しましょう NCache システム要求。 つまり、一般的に、コアについて言えば、多ければ多いほど良いのです。 ただし、一般的には 8 コア以上を推奨します。 主に挙げられるXNUMXつのことは、 NCache 使用するのは、CPU、ネットワーク リソース、メモリです。 CPU は基本的に、受信するリクエストを処理するために使用されます。あるいは、その種の操作を実行するように構成されたサーバー側コードがある場合、それが CPU が使用される理由です。 第 2012 に、RAM はストレージとしてのみ使用され、データが保存された後、通信を維持するためにネットワーク リソースが使用されるため、オーバーヘッドが発生する可能性があります。 たとえば、サーバーからサーバーへの通信、次にクライアントからサーバーへの通信などです。 したがって、これらのオプションの両方がある場合、推奨される Windows Server は 2016、XNUMX です。唯一の前提条件は NCache is .NET frameworkそれ以外の場合は、すべての Windows 環境でサポートされます。

Remote Clients

の面で remote client唯一の前提条件は .NET 4.0 以降であり、クライアントは実際にサポートされます。 あなたが持つことができます NCache それらのサーバー上で。

セットアップ環境

さて、さまざまなことについて話しましたが、基本的なことは、次のとおりです。 NCache、環境を構築する方法について説明します。 そのため、顧客に当社の製品を評価してもらうときは常に、顧客に伝えるべきことを XNUMX つのステップで説明します。 NCache。 まず、新しいコピーをダウンロードします。 NCache Enterprise ウェブサイトから、XNUMX番目はインストールです NCache あなたの環境内で。 私は持っています NCache 私のマシンの 1 台にはすでにインストールされています。 これらは実際にはリモート ボックスのデモ 2 とデモ XNUMX です。 そして、これらのボックスにインストールすると、 NCacheの管理ツールを入手しました。 NCache 呼ばれます NCache マネージャー。 このツールを使用すると、実際にキャッシュを作成、構成し、さまざまな操作を実行したり、 モニタリング がこの事件に関わっている。

キャッシュを作成する NCache マネージャー

それでは、先に進んで開いてみましょう NCache ここのマネージャー。 ただ検索すればいいだけです NCache そしてそれは自動的に立ち上がります。 ということで、開くとこんな景色が広がります。 したがって、ここで行う必要があるのは、新しいクラスター化キャッシュを作成することです。 これを作成するには、「クラスター化キャッシュ」を右クリックし、「新しいクラスター化キャッシュの作成」をクリックします。

したがって、ここで私がしなければならないことは、それに名前を付ける必要があるということです。 ここでは「democache」という名前を付けます。 すべてのキャッシュに名前を付ける必要があります。 ただそれを保つつもりです。 「次へ」をクリックしてみます。

これらは、によって提供される XNUMX つのトポロジです。 NCache 「パーティション レプリカ」は最も推奨されており、すべての顧客の間で最も人気があるため、選択したままにしておきます。 非常に拡張性があり、信頼性が高いです。

これは、パーティション化されたレプリカの場合のアクティブ パーティションとバックアップ パーティション間のレプリケーション戦略です。 高速なため、非同期のままにします。

ここで、このクラスター化キャッシュをホストするサーバーを指定します。 そこで、ここではdemo1とdemo2を指定します。 これらは私が持っている 107 つのボックス 108 と XNUMX で、「次へ」をクリックします。

これは、クラスターが通信するクラスター ポートです。 自動的に拾われます。

これは各ボックスに設定されているサイズです。 したがって、サーバー 2 に 1 つ、サーバー 2 に XNUMX つ、合計 XNUMX ギガのサイズになります。

これらはいくつかの高度なオプションです。 おそらく、キャッシュがいっぱいになるシナリオがある場合、キャッシュはキャッシュからアイテムを自動的に削除できます。 機密データの場合は、項目が勝手に削除されないようにエビクションを実際にオフにすることができます。また、マシンの起動直後にキャッシュを自動開始するオプションもあります。 それで、「完了」をクリックするだけで、実際にキャッシュが作成されます。

ということで、キャッシュの作成はとても簡単でした。 これでキャッシュが設定されました。 キャッシュ名を左クリックすると、さまざまなタブがすべて開き、この時点で必要に応じてさらに変更や構成を行うことができます。

それで、次に私がやろうとしているのは、私の個人的なボックスを remote client。 これを行うには、キャッシュ名を右クリックし、[ノードの追加] をクリックします。

そして、ここでは私の個人ボックスの IP を指定します。つまり 102 ですが、これが追加されました。

したがって、追加したら、キャッシュ名を右クリックして [開始] をクリックするだけです。 したがって、現在、キャッシュは 107 および 108 ボックスで開始されています。 起動して実行したら、統計を開き、監視ツールも紹介します。 NCache 呼ばれます NCache モニターでは、キャッシュ内で起こっている基本的にさまざまな事柄のチェックに関して非常に詳細に説明します。 したがって、キャッシュは現在稼働しています。 統計を開くには、キャッシュ名を右クリックして統計をクリックします。

したがって、これはボックス 107 と 108 の両方についてこれらすべての統計を取得するものです。

それでは実際に開いてみましょう の監視ツール NCache。 これを開くには、キャッシュ名を右クリックし、[モニター クラスター] をクリックします。

　 NCache モニターが開き、サーバー ダッシュボードとレポート ビュー ダッシュボードという XNUMX つの事前設定されたダッシュボードが表示されます。 したがって、これを使用すると、キャッシュ内で何が起こっているかをかなりよく知ることができます。 ここを見ると、これは、たとえば、現在消費されているキャッシュ サイズと、XNUMX 秒あたりのリクエスト数のグラフです。 したがって、現在キャッシュ内で起こっているさまざまな詳細が得られ、これらの詳細を使用して、実際にいくつかのシナリオをデバッグしたり、何らかの問題が発生しているかどうかを解明したりすることができます。

それでは、すぐに元に戻ります NCache ここでは実際に独自のカスタム ダッシュボードを作成することもできます。 ここで事前に設定されているものではなく、確認したい特定のものがあれば、実際にそれを実行することもできます。 ここでは、キャッシュ サーバーのカテゴリにコントロールが存在し、さらにキャッシュ クライアントのカテゴリにもコントロールが存在します。 独自のカスタム ダッシュボードを作成して、実際に興味のあるものだけを表示することもできます。 NCache マネージャー。 このキャッシュに対して実行されているアプリケーションがないため、すべてがゼロと表示されます。

ストレスのシミュレーションとキャッシュ統計の監視

それでは、実際にアプリケーションを実行して簡単にテストしてみましょう。 ここでは PowerShell を開いてあります。 実際にクリアしてみましょう。 実際に新しいものを開いてみましょう。 さて、PowerShell が開きました。 そこで、私がやろうとしていることは、ストレス ツール アプリケーションを実行して、クラスター化されたキャッシュにダミーの負荷を追加し、アクティビティをシミュレートすることです。 したがって、そのアクティビティを使用して、 NCache マネージャーだけでなく、 NCache モニターして、それがどのように機能するかを見てください。

そこで、ストレス テスト ツールを実行します。 もう一度入力する必要があります。 まずプロセスを強制終了しましょう。 それまでの間、ご質問がございましたら、お気軽に [質問と回答] タブに投稿してください。 カル、今のところ質問はないようです。 よし、完璧だ。 何らかの理由でそれは選択されません。 戻ってきました、うん。 申し訳ありませんが、ちょうど言おうと思ったのですが、このセッションは録音されています。 したがって、理由が何であれ、セッション全体に参加できない場合、または最初の部分を見逃した場合は、この録画を確認することができます。 今週後半か来週初めには投稿できると思います。 したがって、先に進んでセッション全体をもう一度進めることができます。

そこで、私が今行っていることは、実際にそのディレクトリに直接移動し、そこでコマンド プロンプトを開いてストレス テスト ツールを実行していることです。 さて、それでは、見てみましょう、はい、取得されました。先に進み、stresstesttool.exe という名前を付けて、デモ キャッシュを付けます。 それで、今何をしているかというと、ダミーのデータをキャッシュに追加することになります。 ここに戻ってくると、現在これら 107 つのボックスで何らかのアクティビティが発生しているのがわかるはずです。 そこにそれがある。 したがって、これらのボックス 108 と XNUMX の両方で何らかのアクティビティが発生していることがわかります。

選択したトポロジでは パーティション化されたレプリカ、各クライアントはクラスター内に存在するすべてのサーバー ノードに接続できるため、両方のサーバーに接続します。 に来たら NCache モニターを見ると、108 つのクライアントが 107 に対して接続されており、もう XNUMX つのクライアントが XNUMX に対して接続されていることがわかります。 NCache XNUMX 秒あたりのリクエストのグラフを見ると、何らかのアクティビティが進行していることがわかります。

したがって、このテストは、すべてが正しいかどうか、キャッシュが正しく構成されているかどうか、すべてが正常に動作しているかどうかを確認するためのものであり、それがテスト済みです。 ということで、ストレステストツールのアプリケーションを停止させていただきます。 さて、話に戻りましょう NCache マネージャー。 先に進み、このキャッシュをクリアして、さらなるテストのためにキャッシュ内にアイテムが存在しないようにしましょう。 つまり、すべてが 0 で表示されます。プレゼンテーションに戻りましょう。 これで環境がセットアップされ、すべての準備が整いました。 今私たちにできることは、スライドを進めることです。

NCache 秘訣 – パフォーマンスの最適化

それでは、パフォーマンスを最適化するために使用する XNUMX つの方法について XNUMX つずつ説明しましょう。 繰り返しますが NCacheクラスター キャッシュはすでにパフォーマンス機能であり、アプリケーション内のパフォーマンスが向上し、データベースのトリップが減少し、メモリ内の分散キャッシュであるより高速なソースからデータを見つけることができます。 ただし、これらの機能は実際には、特定の使用例に応じてパフォーマンスをさらに向上させるのに役立ちます。

• クライアントキャッシュ

  それで、最初にお話しするのは、 クライアントキャッシュ。 それは基本的に、実際のクラスター化されたキャッシュへのアクセスを減らすことです。

• 一括通話

  次に、一括呼び出しについて説明します。これは、単一の操作のみを実行し、単一の呼び出しを使用するだけで、返される複数の操作がサーバー側で処理されるようにすることで、キャッシュへのトリップを削減します。

• 圧縮

  それからあなたも持っています 。 おそらく、オブジェクトのサイズが大きい場合は、これを使用して、追加またはフェッチされるオブジェクト全体のサイズを減らすことができます。 一般に、オブジェクトをより小さいサイズに分割することをお勧めしますが、それが不可能な場合は、圧縮機能を使用できます。

• 非同期更新

  非同期更新もあります。 したがって、これらを使用すると、基本的にアプリケーションは操作の実行を待機しません。 おそらく、これに対して別のタスクを作成し、それに基づいてデータが独自に追加されるようにすることができ、取得したい更新がある場合は、データが追加されたかどうか、または存在するかどうかを確認できます。問題は、それに対するコールバックを登録するだけで済みます。

• コンパクトなシリアル化

  次は コンパクトなシリアル化。 したがって、たとえば、シリアル化可能としてマークされていないカスタム オブジェクトやドメイン オブジェクトが分散キャッシュ内にある場合、それは完全にアウトプロセスであるため、すべてのオブジェクトをシリアル化する必要があります。 したがって、環境内でコードを変更する余裕はないが、カスタム オブジェクトまたはドメイン オブジェクトをシリアル化可能にする必要があるというシナリオの場合は、次のコンパクトなシリアル化機能を使用できます。 NCache すべてをシリアル化可能としてマークし、それを使用して実際に使用を続けることができます NCache あなたの環境内で。 コード変更のないオプションです。 GUI から理解できるものだけで、すべてのセットアップが完了します。

• デュアルNIC

  そして最後に、 デュアルNIC 特徴。 したがって、基本的にクライアントからサーバーへの通信とサーバーからサーバーへの通信のトラフィックを分離し、ネットワーク リソースを分離したい場合は、実際には次のようにすることができます。 NCache。 これは、受信する過剰なトラフィックによってネットワーク リソースが実際に圧迫されている場合にのみ当てはまります。そのようなシナリオの場合にのみ、これをお勧めします。 ただし、その時点でこれらのリソースが最大限に活用されていない場合は、実際には両方の種類の通信に同じネットワーク インターフェイス カードを維持できます。

デモ

それでは、実際に最初のテストを実行してみましょう。このテストでは、アイテムをキャッシュに追加し、キャッシュからアイテムをフェッチします。これを、私たちが持っている基本的な API のベースラインとして使用します。 繰り返しますが、すでに最適化されていますが、これをベースラインとして使用し、その上でさまざまな機能を実行し、それらがどのように機能するかを確認します。

では、最初に、実際にこのサンプルに戻ってみましょう。 したがって、これは実際にこのコードも提供できるサンプルです。 これは、これから説明するベースラインを示すために使用するものです。 テスト 1 では、基本的に 1 個のアイテムをサイズ 5,000 KB のキャッシュに追加し、それらのアイテムをキャッシュからフェッチします。 このテストでは、このコード全体にかかる時間、つまりこのフェッチ部分にかかる時間を取得するだけです。 このフェッチ部分では、100 個の項目をフェッチする必要があるため、ループは実際に 5000 回実行されます。後のスライドでは、この場合にさまざまな機能が実際にどのように役立つかを説明します。

...
try
    {
        cache = NCache.InitializeCache(args[0]);
        cache.Clear();

        Console.WriteLine("TEST 1\n");
        Console.WriteLine("Press anything to add " + objectsCount + " items (100kb Object)");
        Console.ReadKey();
        Console.WriteLine("Adding items now");

        for (int i = 0; i < objectsCount; i++)
            {
                cache.Insert(key + i, obj1);
            }

        Console.WriteLine(objectsCount + " items added. Press any key to retrieve them.");
        Console.ReadKey();
        Console.WriteLine("\nRetrieving " + objectsCount + " items now");
        datetime1 = DateTime.Now;
        ...

それでは、実際に実行してみましょう。 まず、すべてが正しく設定されていることを確認しましょう。 はい、democache test 1 を実行します。 したがって、これもテスト XNUMX です。数値がどのように見えるかについてのベースラインを取得するためのものです。 Enterを押してみます。 キャッシュへのアイテムの追加が開始されます。 戻ってくると NCache マネージャー、ここです。何らかの活動が行われていることがわかります。 つまり、キャッシュにアイテムを追加しています。 レプリカ トポロジのパーティションには 1 つのサーバーがあるため、データはこれらの両方のサーバーに追加され、サーバー 107 (2) とサーバー 5,000 にも追加されます。したがって、データは分割されます。 キャッシュ内のアイテムの総数は XNUMX になります。

したがって、この場合は、実際に完了するまで待ちましょう。完了したら、その数値を実際に書き留めて、後でテストする予定の機能の比較に使用できます。 すでに約 4,000 を超えるアイテムが追加されており、ほぼ完成です。

これは 100 KB のオブジェクトであることに注意してください。これは、ご存知のとおり、テストとしてはかなり大きなサイズですが、これは単に状況がどのように異なるかを示すためのものです。 それらはすべて追加されていると思います、はい、すべて追加されています。 カウンターは実際に停止しました。 Enter をクリックすると、時間がかかりました。Enter をクリックすると、キャッシュからこれらのアイテムの取得が開始され、ここに戻ってくると、取得した時間が表示されます。 したがって、これらのサーバーの両方で、5000 秒あたりのフェッチ数が実際に増加し、XNUMX 秒あたりのリクエスト数も増加していることがわかります。 つまり、実際には、キャッシュからこれらのアイテムをフェッチし始めるために、少しのアクティビティが進行していることがわかります。 キャッシュから XNUMX 個の項目をすべて取得し終わると、画面にタイマーが表示され、そのタイマーを使用して、今後のテストのベースラインとして設定します。

クライアントキャッシュ（キャッシュの近く）

それでは、実際に次のことについて話しましょう。 次に、最初に使用する実際の機能はクライアント キャッシュです。 それでは、クライアント キャッシュとは何なのか説明しましょう。 クライアント キャッシュは基本的にローカル キャッシュであり、クライアント ボックスおよびこれらのクライアント ボックスに存在します。これにより、クラスター化されたキャッシュへのアクセスが削減されます。 クライアント キャッシュは、クラスター化されたキャッシュ データのサブセットです。 クラスター化されたキャッシュ データのローカル コピーをそれ自体とともに保持します。 クラスター キャッシュとの同期は維持されます。

したがって、クライアント キャッシュで実行された更新は、クラスター化されたキャッシュに伝播され、その逆も同様です。 したがって、クラスタ化されたキャッシュで更新されたままになります。アプリケーションがキャッシュからいくつかのアイテムを取得しようとしている場合、それらのアイテムがここにローカルに存在する場合は、そのデータまたはそれらのアイテムを共有するだけです。そして地元の情報源から。

実際に話に戻りましょう。 さて、この操作には約 45 秒かかりました。 したがって、クライアント キャッシュを使用すると、そのシナリオ内でそれがどのように影響するかを実際に確認できます。 Enterをクリックしてみます。 この 45 秒という数字を覚えておきます。

つまり、クライアント キャッシュについてはすでに話しました。 したがって、先ほども述べたように、基本的には XNUMX つの選択肢があります。 クライアント キャッシュを InProc または OutProc として実行できるかどうかは、あなたが理解できることです。 OutProc の場合、別のプロセスが実行され、そのプロセスは残り、クラスター化されたキャッシュとの同期が維持されます。

通常、OutProc プロセスは、複数のアプリケーションまたはアプリケーションの複数のインスタンスを同じボックス上で実行する Web ガーデン シナリオがある場合に推奨されます。 したがって、それらは処理すべき共通のリソース、つまりクライアント キャッシュ、つまり実行中の別個のプロセスを持つことになります。 XNUMX 番目のオプションは InProc キャッシュで、通常、同じボックス上で XNUMX つまたは XNUMX つのアプリケーションが実行されている Web ファーム シナリオの場合に推奨されます。

XNUMX つのケースでは、クライアント キャッシュがアプリケーション プロセス内に存在するために何が起こっていますか。 したがって、この場合、同じプロセスの一部であるため、多くのオーバーヘッドが実際に削除されます。 この場合、シリアル化オーバーヘッド、プロセス間通信オーバーヘッド、これらすべてが実際に削除され、パフォーマンスが大幅に向上します。

OutProc の場合、キャッシュしているのは、アプリケーションがまったく同じボックス上に存在するローカル ソースからデータを取得することです。 したがって、ネットワークトリップは実際に減少します。 したがって、これによりパフォーマンスが大幅に向上し、それが今実際に確認できました。

したがって、ここでは、最初に OutProc として、次に InProc としてクライアント キャッシュを作成し、数値がどのように見えるかを確認します。 そして、現在のシナリオでは、通常の取得で 45 秒かかったと思います。

カル、ここで質問があります。質問は、私たちが話しているすべての機能は同じ製品の一部ですか? つまり、彼らはエディションについて話しているのだと思います。

はい、一部は企業内でのみ利用可能ですが、共有できます エディションの比較 実際にそれらすべての詳細をすべて網羅したドキュメント。 したがって、おそらくそれにより、あなたが探している正確な詳細が実際に得られるでしょう。

この機会を利用して、他の皆さんに質問したいと思いますが、現時点で何か質問はありますか? いえ、質問はありませんので、続けてお話しください。

Out-Proc クライアント キャッシュ

そこで、キャッシュの内容をクリアしてみます。 もう終わりです。 そこで、クライアント キャッシュを作成してみます。 そこで、 NCache マネージャー、ここにクライアント キャッシュが書き込まれています。 ここを右クリックして、「新しいクライアント キャッシュの作成」をクリックします。 なので、ここでは名前はそのままにしておきます。 クライアントキャッシュに設定されています。 すべてデフォルトのままにしておきます。 次に、今は OutProc に設定されていますが、後で InProc に変更します。 「次へ」をクリックします。 サイズは 102 ギガに設定されます。 それはそのままにしておきます。 実際には、これを希望するものに変更したり、クラスター キャッシュの作成時に存在したさらに高度な設定を変更したりできます。 したがって、クライアント キャッシュは実際に私の個人用ボックス、つまり XNUMX に設定されています。

これを確認する簡単な方法は、インストール後に個人ボックス内にあるリスト キャッシュ ツールを実行することです。 NCache そのツールを使用すると、実際にどれがどれであるかを知ることができます。 NCacheは現時点では私の個人用ボックスで実行されています。 さて、ここまで来たら実際にリストキャッシュを実行してみましょう。 私の個人ボックス、つまり 102 にあるキャッシュが表示されています。裏では、まだ何らかの理由でそれを有効にしようとしていると思います。 はい、そこで有効になっているようです。 ここに来ると、クライアントのキャッシュがわかります。 つまり、クライアント キャッシュはここでのローカル キャッシュであり、実行されています。 したがって、現時点では私の個人的なボックスで実行されており、実際に使用できるようになりました。

それで、実際に先に進む前に、それで、何を NCache それは、現在画面に表示されているこれらのカウンターを公開することです。 したがって、Windows パフォーマンス モニターを通じて表示できます。 これから行うことは、Windows パフォーマンス モニターを開いて、使用するクライアント キャッシュのカウンターを開くことです。

そこで、私の個人用ボックスから、パフォーマンス監視を行う PerfMon を検索します。これを使用して、 NCache カテゴリを選択して、クライアント キャッシュである特定のキャッシュを探し、それらのカウンターを開きます。 これで開いたので、新しいパフォーマンス モニターを開いて、次のカテゴリを探します。 NCache。 それがここにあり、ここにクライアントキャッシュが存在します。 「追加」をクリックし、「OK」をクリックします。 ビューをレポートビューに変更してみます。 さて、これらがカウンターです。 使用されていないため、現在表示されているものはすべて 0 です。 OutProc に設定しているため、これは別のプロセスとして実行されます。

私の個人ボックスから数字がどのように見えるかを見てみましょう。 同じコードでアプリケーションを実行します。コードの変更は一切行いません。 クライアント キャッシュ機能はコードを変更する必要はなく、前に述べたように、有効にするか無効にするか、どちらかを選択するだけで、自動的に選択されます。 したがって、同じコード、同じすべて、同じテストであっても、スタート ボタンをクリックすると、「Enter」をクリックすると、それらの項目の追加が開始されます。 さて、Enter をクリックすると、これらの項目の追加が開始されました。 に戻ってきたら、 NCache マネージャーの場合、クラスター化キャッシュに項目が追加されていることがわかります。 開けてみると、 NCache モニター、それはこれです、はい、これです、ここでも何らかの活動が起こっていることがわかります、そしてそれが私が最初に説明したことです。 クライアント キャッシュを構成すると、クライアント キャッシュが使用され、キャッシュに項目を追加すると、クライアント キャッシュもコピーを取得し、クラスター化キャッシュもコピーを取得します。

この使用例は通常、読み取りと書き込みの比率が 80% ～ 20%、または読み取りと書き込みの比率が 70% ～ 30% である場合に推奨されます。 これは通常、大量の読み取りがあり、環境内にある静的データからの参照データがあり、クライアント キャッシュを有効にするとパフォーマンスが大幅に向上するシナリオで推奨されます。

したがって、get API のみをループ内で実行した最初のテストでは、キャッシュからこれらの項目を取得できるまでに 45 秒かかりました。 しかし、このクライアント キャッシュを使用すると、同じボックス上で実行されている別のプロセスで、ローカル ソース内のすべてのデータが検索され、それがどのように機能するかを確認することになります。 したがって、ここで下にスクロールすると、これがクライアント キャッシュの数であることがわかります。 単一のソースであるため、このカウントは 5,000 まで増加する必要があります。 したがって、5,000 個のアイテムはすべてクラスター上に存在し、すべてのサーバー ノードに分散されることになります。 したがって、これらのアイテムが 5,000 に達するのを待ってから、クラスター化されたキャッシュからこれらのアイテムをフェッチするテストの XNUMX 番目の部分を実行します。

したがって、もう 5,000 つ注意すべき点は、キャッシュからアイテムをフェッチすると、呼び出しはクラスター化されたキャッシュに送信されず、現在ローカルにあるクライアント キャッシュによってすべてインターセプトされることです。これがこれから説明することです。ここのカウンターからあなたを待っています。 つまり、これらのカウンターはクライアント キャッシュ カウンターを示していますが、ここに来ると、これらはクラスター化キャッシュのサーバー側カウンターを示しています。 ここで Enter をクリックすると、キャッシュからこれらのアイテムの取得が開始されます。 したがって、ここではカードが移動されていないことをもう一度示します。 だから、ここには電話は来ない。 これを開くと、ここでこのアクティビティが行われていることがわかります。 特定のフェッチが進行中です。 したがって、クライアント キャッシュは現在頻繁に使用されており、書き込みよりも読み取りが多いシナリオでクライアント キャッシュを使用することの重要性はそこにあります。 したがって、数秒後、クライアント キャッシュ シナリオからサイズ 100 KB の 45 個のアイテムを表示するのにどれくらいの時間がかかったかの結果がここに表示されます。 つまり、環境内で OutProc クライアント キャッシュが有効になっている場合、33 秒から XNUMX 秒に短縮されたことがわかります。

したがって、大きな改善であることがわかります。 目に見えるのは 10 秒以上で、アプリケーションの観点から見ると、これは大きな時間です。 したがって、このケースでは大きな改善が見られました。

インプロセスクライアントキャッシュ

そこで、ここでインプロセス クライアント キャッシュを作成し、そのインプロセス クライアント キャッシュを使用して、実際のテストの 45 秒、テストの 33 秒と比較してパフォーマンスを確認します。クライアント キャッシュ OutProc テスト。 したがって、まず最初にこのキャッシュを削除します。 現在は削除されています。 新しいキャッシュを作成してみます。 繰り返しますが、その横に「InProc」と入力して「次へ」をクリックし、分離レベルを InProc のままにし、すべてをデフォルトのままにして、「終了」をクリックします。 それで、これが私の個人用ボックス上に作成され、まったく同じテストを実行します。 実際には、まずキャッシュ内のデータをクリアしましょう。

それで、同じテスト、同じ引数、そして私はそれを始めたばかりです。 したがって、今度はまったく同じテストを再度実行します。 5000 個のアイテムをサイズ 100 KB のキャッシュに格納すると、クライアントの InProc クライアント キャッシュを使用してそれらのアイテムがフェッチされます。 コンセプトはまったく同じです。 アプリケーションがキャッシュに項目を追加すると、In Proc として実行しているため、まったく同じプロセス内に存在するクライアント キャッシュにも項目を追加することになります。 したがって、これらのアイテムはクライアント キャッシュにも追加され、クラスター化されたキャッシュにも追加されます。 それで、それが完了したら、今すぐ「Enter」をクリックします。 そのため、これらのアイテムを取得すると、ローカル内で、まったく同じプロセス内でそれらすべてのアイテムが検索されます。

そのため、プロセス間通信やシリアル化、逆シリアル化などのオーバーヘッドが発生することなく、それらすべてが完全に削除されるようになりました。 データをローカル ソースから直接取得し、この特定のシナリオで InProc モードでクライアント キャッシュが実際にどの程度のパフォーマンスを発揮しているかを確認します。 ということで、あとはアイテムが追加されるのを待つだけです。 ここに戻ってくると、カウンターがいくつか上がったり下がったりしているのが見えるはずです。 それは間違いなくわかります。

それで、それまでの間、皆さん、何か質問があれば、ぜひお知らせください。 サムは質問ドックタブに注目しています。 何か質問があれば彼は私に知らせるつもりです。

したがって、リストで先ほど述べたように、次は一括操作になります。 したがって、バルク API を使用する 3000 つのものだけをテストします。 ただし、一括操作とまったく同じ方法で実行されるさまざまな概念があり、このプレゼンテーションではこれらすべてを理論的に説明します。 実際にどれくらいの項目が追加されるのか見てみましょう。 ということで、すでに約5000点以上のアイテムが追加されています。 したがって、完全な XNUMX マーカーに達するのを待っているだけです。その後、これがどのように機能するかを確認します。 さて、最初のものに固執しました。 ということで、後は裏で手術が行われるのを待つだけです。 それまでのところ、ここでは一括操作の場合の最初のことについて話しているだけです。

したがって、一括操作の中心的な概念は、クラスター化されたキャッシュに入る実際の呼び出しの量を制限することだけです。 したがって、すでに行ったように、これらすべての処理をループ内で実行する代わりに、実際には、それらとまったく同じ呼び出しを XNUMX つの操作の一部として実行できます。 したがって、単一の操作をクラスター化キャッシュに送信し、それに対して複数の操作を実行できます。 したがって、大量の場合に共有する場合は、キーを知っておく必要があります。 したがって、たとえば、追加するキーと実際のオブジェクトを指定するだけで、XNUMX 回の呼び出しを行うだけで、それらすべてのアイテムが実際に後方のクラスター化キャッシュに追加されます。

ですから、それらは完了すべきだと思います、はい、それらはもうほぼ完了しています。 ここに戻ってくると、これらすべての項目が追加されました。 Enter をクリックすると、これらの項目がすべて取得されたことがわかります。 多くのオーバーヘッドが削除されたので、これを見るのは非常に驚くべきことです。 つまり、非常に速かったのです。 したがって、最初に行ったテストを繰り返すと、基本テストでは 45 秒かかりましたが、クライアント キャッシュ OutProc では約 33 秒かかりました。 ただし、InProc クライアント キャッシュの場合、この時間はすべて 0.1 秒に短縮されました。

つまり、あなたのユースケースがここで進めているユースケースに当てはまれば、InProc クライアント キャッシュでどの程度の改善が見られるかということになります。 つまり、これは大きな改善であり、より多くの読み取りと書き込みが行われている場合に確認できます。

したがって、「Enter」をクリックするだけです。 それで、それは近づいています。 ここでこのクライアント キャッシュを削除し、実際にもクリアします。 さて、プレゼンテーションに戻りましょう。 さて、ここで、私たちは一括操作について話しました。

一括取得 (キーベース)

したがって、一括操作の場合、最初の方法は、追加したいアイテムが多数ある場合、またはキャッシュからフェッチしたいアイテムが多数ある場合は、それに応じてリストを提供するだけで済みます。 XNUMX 回の呼び出しだけで、キャッシュ上でこれらすべての操作を実行できます。 したがって、一般に、オブジェクト サイズが大きい場合は、それを複数のオブジェクトに分割してから、次の機能を使用することをお勧めします。 NCache 実際にそれらをグループ化したり、取得したり、キャッシュに追加したりすることもできます。 したがって、これらのシナリオでは一括 API を使用できます。 XNUMX 番目の方法は、たとえば、これらの項目のキーがわからない場合です。一括処理はキーベースの操作であったため、すべてのキーを知っている必要があります。

SQL/LINQ検索クエリ

SQL または LINQ タイプの検索クエリでは、基本的にキーがわからなくても、実際には特定の条件に基づいて検索できます。 たとえば、キャッシュ内に製品を追加している場合、特定の基準に基づいてキャッシュから複数の製品を実際にフェッチできます。 そこで、次の名前でクエリを実行するとします。 '製品を選択してください WHERE product.price > 10 AND product.price < 100'。 したがって、その特定の基準を実際に満たし、キャッシュ内に存在するすべての製品が実際に返されることになります。 したがって、この場合はキーを指定せず、条件を指定するだけで、キーが返されました。

グループとサブグループ

次は、キャッシュ内に論理コレクションを作成できるかどうかです。 両方をグループ、サブグループ、そしてタグとしてまとめて説明します。 それで、それができます。 したがって、たとえば、顧客とその注文がキャッシュ内にある場合、実際にすべての注文をグループ化できます。 キャッシュには個別の項目があるため、実際にはコレクションも保持できますが、分割することをお勧めします。通常、キャッシュから項目を取得すると、完全なオブジェクトは必要なくなり、そのオブジェクトに対する特定の値が必要になるからです。 したがって、それを複数のオブジェクトに分割すると、より効率的に使用できます。 したがって、これらの論理コレクション機能を使用すると、基本的にキャッシュ内の項目をグループ化できます。 したがって、特定の顧客のすべての注文を XNUMX 回の呼び出しでグループ化できます。 グループの場合はグループごとに取得を実行でき、タグの場合はタグごとに取得できます。顧客 ID を指定するだけで、キャッシュ内に存在するすべての関連アイテムが実際に返されるとします。 繰り返しますが、この場合、キーを知る必要はありません。グループまたはタグである特定の文字列値を知っていればよく、それに基づいてそれが返され、並列クエリもサポートされます。

一括操作 - デモ

それでは、実際の一括操作のサンプルに取り掛かりましょう。 それで、このテストに戻ってくるなら、ここです。 これは一括テスト、つまりテスト 2 であり、実際に実行します。 まず実際に起動してみましょう。それから、その動作の詳細を見ていきます。 それで、今、テスト 2 に変更して開始しました。 つまり、このテストが行​​っていることは、基本的に、現在、サイズ 10,000 KB の 10 個のアイテムをキャッシュに追加しているということです。 まず、これらの項目をキャッシュに追加する基本的な挿入だけを実行し、次にこれらの項目をすべてフェッチし、追加とフェッチ部分の時間も実際に記録します。

Console.WriteLine("TEST 2\n");
Console.WriteLine("Press anything to add " + objectsCountBulk + " items (10kb Object)");
Console.ReadKey();
Console.WriteLine("Adding items now");
datetime1 = DateTime.Now;
for (int i = 0; i < objectsCountBulk; i++)
{
    cache.Insert(key + i, obj2);
}
datetime2 = DateTime.Now;
Console.WriteLine(objectsCountBulk + " items added. Time to add " + objectsCountBulk + " items in a loop: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nPress any key to retrieve them.");
Console.ReadKey();

したがって、それが完了すると、サイズ 10,000 KB のアイテム 10 個をキャッシュに追加するのにかかる時間のベースラインを取得し、一括操作を開始します。 これらの一括操作では、同じ呼び出しで 10,000 個のアイテムすべてがキャッシュに追加され、事前定義されたキー リストとオブジェクト リストを使用して XNUMX 回の呼び出しで再度フェッチされます。

OK、[Enter]をクリックします。 これらのアイテムのキャッシュへの追加が開始されます。 戻ってくると NCache マネージャー、ここで何らかの活動が行われていることがわかりました。 これらのアイテムは、現在存在する両方のサーバーに追加されています。

モニター クラスターを見ても、ここに 10,000 つのクライアントが接続され、そこに 10,000 つのクライアントが接続されており、これらのグラフで少しのアクティビティが発生していることがわかります。 したがって、これを使用すると、実際にキャッシュ内で何が起こっているのか、何が使用されているのか、現時点で何が使用されていないのか、そしてどれだけ使用されているかをかなりよく知ることができます。 追加された 37 項目はほぼすべて完了したと思います。 はい、そうです。Enter キーを押してこれら 10,000 個のアイテムを取得します。 したがって、まず、これらのアイテムをキャッシュに追加するのに約 30 秒かかりました。 ここで、キャッシュから 10,000 個のアイテムを読み取ります。 ご覧のとおり、これらのサーバー ノードの両方で 10,000 秒あたりいくつかのフェッチが行われていることがわかります。 したがって、アイテムは現在取得中です。 したがって、今はループでフェッチしています。 完了すると、一括テストが開始されることに注意してください。 したがって、その一括テストに基づいて、これら 10 つの数値を比較し、それらが実際にどのような影響を与えるかを確認します。 したがって、ここでは、これらの 37 項目を取得するのに約 10,000 秒かかりました。バルク API を使用して実際に追加が完了しました。フェッチ部分も間もなく完了するはずです。そうそう、Enter キーを押す必要があると思います。 OK、実際に完了するまで待ちましょう。そうすれば、これらすべてがどのように見えるかを実際に示すことができます。 これで完成です。 したがって、このテストを詳しく見てみると、ループを使用してサイズ 30 KB の 10,000 個のアイテムがキャッシュに追加され、約 5 秒かかりました。 これら XNUMX 個のアイテムを取得するには、再びループして約 XNUMX 秒かかりました。 一括テストでは、これらの XNUMX 項目がキャッシュに追加され、所要時間は約 XNUMX 秒でした。

つまり、これは 37 秒と 5 秒の間には大きな差があり、これらのアイテムをキャッシュに取得するには、たとえば約 6 秒かかりました。 そうすると、6秒と30秒ではまた大きな差が出ます。 つまり、これが一括操作によって実際にユーザーとアプリケーションにどの程度の改善がもたらされるのかということです。これを使用すると、同じ呼び出しを何度も実行する必要がなくなります。 毎回クラスター化キャッシュにアクセスする必要はありません。 基本的に、一括 API を使用して、実行する必要があるすべての操作のコレクションを作成し、それらをキャッシュに追加するだけです。

圧縮 - デモ

これで、一括テストが実際に完了しました。 さて、プレゼンテーションに戻ります。 さて、次は圧縮テストです。 繰り返しますが、前に述べたように、通常はオブジェクトをより小さいサイズに分割することをお勧めしますが、そのオプションが利用できない場合は、実際に圧縮し、実際に特定のしきい値を設定することができます。 それより大きいオブジェクトは、より小さいサイズに圧縮されません。 では、実際に環境で圧縮を有効にしてみましょう。 したがって、まず第一に、キャッシュをクリアしましょう。 完了しました。 圧縮はその場で実行できるものです。 したがって、キャッシュを停止する必要はありません。 したがって、キャッシュ名を左クリックすると、さまざまな設定がすべて開きます。 ここに移動してオプションを開くと、圧縮を有効にするをクリックするだけです。 50KBに設定してみます。 したがって、50 KB を超えるものはすべて圧縮されます。 キャッシュ名を右クリックし、「構成の適用」をクリックします。 これらすべての構成がクラスターに適用されます。 したがって、それより大きいオブジェクトは実際には圧縮されます。

そこで、最初に行ったのと同じテスト (テスト 1) を実行します。テスト 1 に戻し、これを保存して、実行 (開始) をクリックします。 開始されるのを待ちましょう。その後、さまざまなシナリオで圧縮が実際にどのように役立つかについて詳しく説明します。 圧縮がどのように機能するかというと、クライアントがこれらのアイテムをキャッシュに送信すると、圧縮された状態で送信されます。 つまり、圧縮がどのように役立つかというと、アイテムがネットワーク上を移動するとサイズが小さくなり、クラスター化されたキャッシュに留まると、場所を占める場所も少なくなります。

カル、思い出してもらいたいのですが、セッション終了まであと 10 分ありますので、それに合わせてペースを調整してください。 そうですね、わかりました、ありがとう。 この時点で何か質問はありますか？ いや、みんな仲が良さそうだね。 実際のところ、確認が XNUMX つありますが、これまでのところ、問題はありません。 よし、完璧だ。 ありがとう。

さて、圧縮がどのように役立つかについて話しました。 したがって、1 つのことが考えられます。小さいサイズのオブジェクトのネットワーク全体の移動は、大きいサイズのオブジェクトよりも明らかに高速になります。そのオブジェクトがキャッシュ内に配置されたら、Enter をクリックすると、これらのアイテムの取得が開始されます。 。 したがって、キャッシュ内に配置されると、実際にはサイズも小さくなります。 したがって、消費するスペースが少なくなります。 このアイテムの処理にかかる時間全体も短縮されます。 これが、シナリオ内で圧縮がどのように役立つかということです。 追加中にクライアント側でオーバーヘッドが発生します。 しかし、私たちが今気づくことになる全体の純的な改善は、実際にはそれよりも大きいものです。 したがって、これらのアイテムに対する操作全体が見つかるまでにかかる時間は、実際にははるかに高速になります。 したがって、テスト 26 は圧縮で完了し、約 XNUMX 秒かかりました。

覚えていると思いますが、最初に何も行わず、特別な機能も含まず、基本的な API のみを使用した最初のテストでは、45 秒かかったと思います。 つまり、45秒と26秒の間には大きな違いがあります。 つまり、圧縮が実際に役立つのはこの程度であり、これらの操作がさらにスケールアウトされると、この場合にはさらに大きな違いが生じることになります。 したがって、この場合にはそれが非常に役立ちます。

非同期操作 - デモ

それでは、実際に次のシナリオ、つまり非同期更新に進んでみましょう。 非同期更新では、基本的にアプリケーションは待機しません。 別のタスクを設定すると、そのタスクがそれらの操作を実行することになります。 どのようなシナリオでも、項目が追加されたかどうか、または追加されなかった場合の情報のみを取得するコールバックを設定できます。 実際にそれを設定することもできます。 今すぐサンプルに行きますが、テスト番号 3 だと思いますが、それはすぐに確認できます。 さて、これは非同期更新のテスト番号 3 です。 実際に起動して、コードの詳細を見てみましょう。 制御できるようになり次第、コード ファイルを開いて、非同期更新のテスト番号 3 で何が起こっているのかを実際に示します。 今から始めました。 したがって、非同期更新では、テスト番号 3 が行われます。まず最初に基本的な挿入呼び出しだけを使用してアイテムをキャッシュに追加し、その後、それらのアイテムの追加が完了すると、基本的に、アイテムの一部でアイテムを再度削除します。ループ。 したがって、各キーは XNUMX 回の反復で削除されます。

...
else if (args[1].Equals("test3"))//ASYNC API TEST
{
    Console.WriteLine("TEST 3\n");
    Console.WriteLine("Press anything to add " + objectsCount + " items normally (100kb Object)");
    Console.ReadKey();
    Console.WriteLine("Adding items now");

    try
    {
        cache = NCache.InitializeCache(args[0]);
        datetime1 = DateTime.Now;
        for (int i = 0; i < objectsCount; i++)
        {
            cache.Insert(key + i, obj1);
            //cache.InsertAsync(key + i, obj1, OnItemAdded, "", "");
        }
...

Enterをクリックしてみます。 サイズ 5,000 KB のキャッシュに 100 個のアイテムが追加されており、それが通常どおり行われています。 ここで通常とは、単に単純な挿入を意味し、その後ループの一部でそれらの項目を再度削除します。 したがって、これを使用して、この部分にかかる時間を確認し、その後、追加、非同期挿入、およびそれらの削除に非同期呼び出しを使用します。 これらのアイテムを追加している間に、実際に戻ってどのように見えるかを見てみましょう。 したがって、この場合は、これらのアイテムを削除するための基本的な削除を行っているだけです。 非同期テスト部分では、挿入非同期呼び出しを行っています。 したがって、クライアントは待機せず、操作をキューに渡すだけです。 キューはプロセスが遅いという意味ではなく、クライアントはそれを待たず、バックグラウンド プロセスとして実行されますが、かなり高速に実行されます。 なぜなら、キャッシュ内の多くの操作は実際には非同期で実行されるからです。

...
datetime2 = DateTime.Now;
Console.WriteLine("Time to remove " + objectsCount + " objects normally: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nAdding items using Async API now");
datetime1 = DateTime.Now;

for (int i = 0; i < objectsCount; i++)
{
    //cache.Insert(key + i, obj1);
    cache.InsertAsync(key + i, obj1, OnItemAdded, "","");
}
datetime2 = DateTime.Now;
Console.WriteLine("Time to add " + objectsCount + " objects with Async API: " + (datetime2 - datetime1).TotalSeconds);
Console.WriteLine("\nRemoving " + objectsCount + " items with Async API now");
...

例を挙げてみましょう。 たとえば、レプリケーションについて話している場合、キャッシュ作成プロセスでそれを非同期に設定したことを思い出してください。 したがって、それを使用して、基本的にそれらの多くはバックグラウンドプロセスとして実行されます。 彼らはとても信頼できます。 アプリケーション、メインプロセス、メインタスクは影響を受けないというだけです。 したがって、これらのアイテムをキャッシュに追加するのに約 49 秒かかりました。 現在、実際にこれら 5,000 個のアイテムが削除されています。 それが完了したら、非同期呼び出しがどのように行われるかを見ていきます。 したがって、5,000 個のアイテムを移動する必要があります。 これらの項目を削除するのに約 25 秒かかりました。現在は非同期呼び出しを使用して項目を追加しています。49 秒と、いつ取得するかという点でどれだけの差が得られるかを確認します。アイテムをキャッシュに追加しています。 そこにそれがある。 つまり、加算部分では 49 秒から 28 秒に減り、それらの項目を除いた場合には 25 秒から 1.6 秒に減りました。 つまり、これを組み込むと実際に確認できるパフォーマンスはこのくらいになります。 したがって、大きな違いがあることがわかります。 基本的な削除呼び出しからアイテムを削除する場合と、非同期削除呼び出しからアイテムを削除する場合とでは、約 25 秒の違いがあります。 したがって、それは、によって提供されるこの種の機能から期待できることです。 NCache.

デュアル NIC - デモ

実際にプレゼンテーションに戻りましょう。 非同期について説明しました。次はコンパクトなシリアル化です。 したがって、繰り返しになりますが、これは、コード内で更新を行う余裕がないシナリオで取り上げられており、これを使用すると、実際にすべてのクラスをシリアル化可能としてマークできます。 カルがそうコメントしました。あと 3 分ほど残っていますので…そうです、そうです。 すぐに隠蔽するつもりです。 つまり、最後に残った XNUMX つのことは、XNUMX つはコンパクトなシリアル化であり、XNUMX つ目はデュアル NIC 機能です。 したがって、前に述べたように、ネットワーク リソースが限界に達している場合、デフォルトでは、サーバー間通信とクライアントからサーバーの通信の両方が、まったく同じネットワーク インターフェイス カード上で発生します。 ただし、ネットワーク リソースが限界に達していることがわかった場合にできることは、クライアントからサーバー間の通信と、サーバーからサーバー間の通信の種類を分離することです。 それは非常に単純なタスクです NCache マネージャー。 ここに来たら、ここを右クリックして [NIC の選択] をクリックして選択します。

NIC を選択すると、この特定の IP 上でどの通信を実行するかを実際に指定できます。 私は XNUMX つしか持っていないので、これらのオプションを利用できます。 複数の IP がある場合は、実際にその場で選択できます。 したがって、「キャンセル」をクリックするだけです。

時間が足りなかったため、コンパクトなシリアル化デモを行う機会はありませんでしたが、実際にこのサンプルを皆さんと共有することができ、テストしてそれがどのように機能するかを確認することができます。 サム、あなたのところへ。 完璧。 では、カルさん、お時間をいただきまして誠にありがとうございます。

今日のセッションを終了する前に、何か質問はありますか? 何か質問がないか確認するために少し時間をいただきたいと思います。 さて、それでは質問があります。

このプレゼンテーションを共有するリンクを共有していただけますか? それで、カル、それは私たちのウェブサイトで入手できると思いますね?

はい、利用可能になる予定です。そこにメールアドレスをメモしておきます。 したがって、私にできることは、アップロードされたらすぐに電子メールを送信することです。 わかりました。 実は、もう一つ質問があります。

プレゼンテーションをスケジュールしてもいいですか、それでは、チームのデモをスケジュールしてもいいですか?

そのとおり。 もちろんデモをスケジュールすることもできます。 弊社のサポートチームにお問い合わせください support@alachisoft.com または当社の営業チーム sales@alachisoft.com ご希望の時間帯をお知らせいただければ、喜んでお客様専用のセッションを予定させていただきます。

さて、カル、それでは先に進んでこれを終わりにします。 これ以上質問はないと思います。 本日はセッションにご参加いただきまして、誠にありがとうございます。 先ほども言いましたが、ご質問がある場合はサポート チームにお問い合わせいただくか、販売関連の質問については営業チームにお問い合わせください。 私たちがお手伝いいたします。 お気軽にお電話ください。 お電話で直接ご連絡いただくことも可能です。 当社のウェブサイトにあります。 次回まで、本当にありがとうございました、そして、こんばんは、さようなら。

次はどうする？

• NCache 詳細
• ダウンロード NCache
• パーソナライズされたLIVEデモをリクエストする