複数のクライアント（ブラウザー、他のアプリケーション、UNIXシェルスクリプト、Pythonスクリプトなど）からの同じリソースのJSON表現についてかなり厳しくポーリングされているサイトがあります。
リクエストの処理とリソースのJSONへのシリアル化によるCPUヒットを回避するために、一部のリソースが構成可能な期間サーバー内にキャッシュされるように、キャッシュを追加したいと思います。もちろん、ハンドラー内に自分でキャッシュすることもできますが、リクエストごとにシリアル化のヒットが発生し、ハンドラーの負荷も変更する必要があります。
openrasta-cachingモジュールを見てきましたが、これはブラウザのキャッシュを制御するためだけのものだと思いますか？
では、コーデックがリソースを生成した後、openrastaにリソースのレンダリングされた表現をキャッシュさせる方法についての提案はありますか？
ありがとう
openrasta-caching は、ServerCaching 属性を使用して、asp.net サーバー側キャッシュにマップできる API を使用して、サーバー側キャッシュを予備的にサポートしています。それは完全ではないと言いました.openrasta-cachingもそうではありません. asp.netキャッシングインフラストラクチャが現在サポートしていない、サポートしたいすべてのシナリオを完全にサポートする適切なv1にするには、2、3日の作業が必要になる0.2です（主に、OpenRastaのキャッシングを機能させるオブジェクトではなくhttp仲介とまったく同じで、asp.netランドに存在する.net中心のものであり、クライアントがサーバーに強制的にクエリをやり直すことを許可したい場合のサーバーキャッシュのクライアント制御を含みます)。現在、キャッシングに取り組んでいるクライアント プロジェクトがないため、そのプラグインに関するこれ以上の作業を正当化することは困難です。そのため、今は何もコーディングしていません。ただし、4 日間の無料期間が近づいているので、openrasta-caching を 0.3 に増やしたい場合は、4 日間の作業に適合する要件が何であれ、私に DM してください。
IOperationInterceptor を使用してより単純なものを実装し、それを使用して asp.net パイプラインをプラグインするか、より Web フレンドリーにして squid を使用してプロセス外でキャッシュを実装し、openrasta-caching を使用して正しい http キャッシュ命令を生成することができます。
とはいえ、あなたの問題では、コストがjsonの場合、サーバーのキャッシュさえ必要ないかもしれません。最後に変更されたものまたは Etag をハンドラーが返すものにマップする304と、クライアントが条件付きの要求を行う (そうする必要がある) 場合、適切な場所で適切に生成され、json レンダリングがすべてバイパスされます。
最後に変更された/etag に対して最初のクエリを実行して、データを取得せずに 304 を返すことで、API をさらに最適化できるようにする提案された API もあります。