残念ながら、大規模なデータセットを操作する場合、構造のシリアル化と逆シリアル化には常に時間がかかります。 DataTable 特に、基本的なテーブルのように見えても、多くのメタデータが添付されている行と列があるため、かなり複雑なオブジェクトです。
DataTable vsList<POCO> ：
本当にDataTableとしてシリアル化する必要があるかどうかを検討してください 。より単純なPOCOを作成し、List<YourRecord>をシリアル化できますか ？つまり、フィールドと列に追加の属性を必要とせず、より単純な形式にシリアル化できる場合は、キャッシュ内でより高速でスペース効率が高くなる可能性があります。次に、DataTableに復元します 必要に応じて。
別のオプションは、DataTableを分割することです 小さなセットに分割し、シリアル化して小さなパーツに保存します。これはよりパフォーマンスが高いと感じるかもしれません。 これをベンチマークできるはずです。
ベンチマーク：
最終的に、Redisキャッシュは、データソースの再クエリにかかる時間よりも改善されるはずです。 takes too much timeという用語を使用します 、ただし、キャッシュから取得するのに2秒かかるのに対し、データソースをクエリするのに8秒かかる場合は、大幅に向上します。しかし、確実にする唯一の方法はベンチマークすることです。
-
必要なツールのみを実行するように環境をセットアップします。 ベンチマークの実行中に他のタスクを実行しないでください。バイアスを導入しないでください。
-
DataTableのシリアル化にかかる時間を記録します 。このアクションを何度も実行し、平均します。var start = DateTime.Now; // Serialize var duration = DateTime.Now - start; -
さまざまなサイズの
DataTableを試してください sそして許容できる時間を見つけるかどうかを確認します。 -
JSON.NETなどの別のシリアル化ライブラリを試してください。すべてのServiceStackを保持するのは良いことですが、これはServiceStack.Textの欠点なのか、それとも大規模なデータセットの問題なのかを判断するのに役立ちます。
-
逆シリアル化のプロセスを繰り返します。
メモリ：
大規模なデータセットを使用している場合、アプリケーションとキャッシュの両方に十分なメモリがありますか？アプリケーションのメモリがボトルネックになる可能性があります。操作の実行中は、システムのアクティビティモニターを監視し、メモリが不足していないこと、およびシステムにページングを実行させていないことを確認する必要があります。これが発生している場合は、RAMを増やすか、前述のようにDataTableをより小さなデータセットに分割することを検討してください。
レイテンシ：
同じマシンではなく、ネットワーク経由でRedisサーバーに接続している場合、ネットワークの遅延を確認しましたか？アプリケーションサーバーとキャッシュサーバーの間でpingを実行し、実際にpingが低いことを確認することをお勧めします。特に、単純なオブジェクトのキャッシュが遅い場合。
Redis？
キャッシュと復元の時間を改善する方法がない場合は、Redisを使用するのは適切ではない可能性があります。おそらくstatic DataTableを使用しています アプリケーションメモリ内がより適しています。つまり、アプリケーションメモリにキャッシュを保持することで、心配する必要のあるシリアル化と逆シリアル化がなくなります。もちろん、これを行うためにアプリケーションで使用可能な十分なメモリがあることを確認するために注意する必要があるかもしれません。 ただし、このオプションを選択する必要がある場合は驚きます 。
概要：
データセットや構築しているサービスの知識がなければ、最終的には、問題の原因を最も適切に絞り込む方法についての一般的なアドバイスにすぎません。重要なアドバイスは、DataTableを使用しないことです。 より単純な構造で十分な場合は、各操作のベンチマークを行ってボトルネックを特定します。
これがお役に立てば幸いです。