タグ付けされた質問 「caching」

順序付け/プロパティを変更できるページ分割された検索結果をキャッシュするためのベストプラクティスは何ですか？ 私のアプリケーションでは、誰かが最新の20のディスカッションスレッド（10,000のうち）を見たいとします。servletXML、JSONとしてディスカッションスレッドテーブルから最初の20レコードを取得するために、を介してデータベースにリクエストが送信されます。その後、次の20を表示したい場合、結果の次のページに移動し、次のロットを取得するための別の要求を開始します（制限とオフセット= 20など）。 サーバーの負荷とクライアント待機を減らすために、結果の前のページをキャッシュしたいと思います。ただし、2つの質問があります。 結果が表示されるテーブルは、複数の属性（つまり、thread-creation-date、thread-author、last-post-date）で並べ替えることができます。これは、「最初の20件の結果」のような文は、コンテキストなしでは意味をなさないことを意味します（つまり、私たちは何によって注文するのか）。それでは、フロントエンドはどのようにしてバックエンドに既にロードしたものと通信しますか？最初に考えたのは、各結果にIDを使用することでしたが、後続のリクエストでIDをサーバーに送り返す（およびそれらに基づいて結果をフィルタリングする）のは、すべてを盲目的に送り返すのと同じくらい時間がかかります。これどうやってするの？ 以前に返された結果（つまり、最新のポスト日付）の属性が変更された場合はどうなりますか？次に、各結果をチェックインして、ページインされてからサーバー側で変更されているかどうかを確認する方法が必要です。これを行うにはどうすればよいですか？

11 ajax  caching  pagination 

私は.NET 4.0アプリケーションに取り組んでいます。これは、doubleを返す2つのdoubleに対してかなり高価な計算を実行します。この計算は、数千のアイテムのそれぞれに対して実行されます。これらの計算はTask、スレッドプールスレッドで実行されます。 いくつかの予備テストでは、同じ計算が繰り返し実行されることが示されているため、n個の結果をキャッシュしたいと思います。キャッシュがいっぱいになったら、最近使用したアイテムのうち、最も使用頻度の低いアイテムを破棄したいと思います。（編集：キャッシュがいっぱいになったときので、私は少なくとも、しばしばを実現することは、意味がないと私は1つが最も頻繁に使用されると、すぐに新しい結果が計算され、次回に置き換えられるであろうと、新たに計算されたものと結果を置き換えますキャッシュに追加されました） これを実装するために、私はDictionary<Input, double>（Input2つの入力double値を格納するミニクラスになる）を使用して、入力とキャッシュされた結果を格納することを考えていました。ただし、最後に結果がいつ使用されたかを追跡する必要もあります。このためには、キャッシュがいっぱいになったときに辞書から結果を削除するために必要な情報を格納する2番目のコレクションが必要だと思います。このリストを常にソートしておくと、パフォーマンスに悪影響が出るのではないかと心配しています。 これを行うためのより良い（つまりよりパフォーマンスの高い）方法、または私が知らない一般的なデータ構造さえありますか？ソリューションの最適性を判断するには、どのようなことをプロファイリング/測定する必要がありますか？

11 .net  data-structures  caching 

YouTube動画の再生回数が常に遅れていることに注意してください。たとえば、動画には1000件のコメントがあり、500ヒットがあり、数時間後には10000ヒットになります。 これはYouTubeだけではありません。ほとんどのメッセージボードはそのように実装されており、再生回数は10分ごとなどに更新されます。 誰かがこの背後にある理由を知っていますか？ ありがとう。

10 caching 

L1キャッシュを備えたCPUが書き込みを行うと、通常、（データの更新に加えて）書き込み先のキャッシュラインがすでにL1キャッシュにあると想定して、キャッシュがそのキャッシュラインをダーティとしてマークします。 、後で更新されたデータを含む行を書き出します。 可能な最適化の1つは、キャッシュに書き込みの内容と以前のキャッシュの内容を比較させ、それらが同じである場合、その行をダーティとしてマークしないことです。これにより、キャッシュでライトバックを回避できる場合があるため、CPU製造元がこのロジックを実行するために必要なゲートに値するものとして、これをどのように認識しているかを確認できます。 私の質問：この最適化を実行するCPUはありますか？ なぜ私が尋ねているのかについての背景：一定のメモリアクセスを必要とするいくつかのコードを書いています。つまり、キャッシュの動作を聞くことができる人は、私がしていることを推測できないはずです。私のアクセスの一部は書き込みであり、このコードを実装する明白な方法では、書き込みの多くは、すでに存在するものと同じデータを書き込みます。書き込みを行う必要があるのは、データによっては、書き込んでいるデータが同じである場合とそうでない場合があり、同じアクションを実行することが重要であるためです。CPUが「no-change-write」を実際に書き込まないことによって最適化する場合、それはキャッシュの動作が私がやっていることによって異なり、それが私の目標を覆すことになることを意味します。 それで、この方法で書き込みを最適化しようとするCPUはありますか？

9 caching  cpu 

同じコンテンツをリクエストするために、承認が必要な同時ユーザーの非常に大きなインパルスを処理する必要があるWebアプリに取り組んでいます。現在の状態では、32コアのAWSインスタンスでさえ完全に機能しなくなっています。 （Nginxをリバースプロキシとして使用していることに注意してください） 最悪の場合、JWTをデコードしてユーザーが認証されているかどうかを確認する必要があるため、応答を単純にキャッシュすることはできません。これは、ほとんどが同意するだろうLaravel 4、最大発射たち必要です遅い PHP-FPMとOpCacheが有効になっていても、。これは主に、ブートストラップ段階が多すぎるためです。 「これが問題になることがわかっているのに、なぜPHPとLaravelを最初に使用したのですか？」-しかし、その決定に戻るには今では遅すぎます！ 可能な解決策 提唱されている1つの解決策は、LaravelからAuthモジュールを軽量の外部モジュール（Cなどの高速なもので記述）に抽出することです。このモジュールの責任は、JWTをデコードし、ユーザーが認証されるかどうかを決定することです。 リクエストの流れは次のようになります。 キャッシュヒットかどうかを確認します（通常どおりPHPに渡されない場合）。 トークンをデコードする 有効かどうかを確認する 場合は、有効な、キャッシュからサーブ 無効な場合は、Nginxに通知すると、NginxはリクエストをPHPに渡し、通常どおりに処理します。 これにより、このリクエストを1人のユーザーに提供した後はPHPにヒットせず、代わりに軽量モジュールに手を伸ばして、JWTのデコードやこのタイプの認証に伴うその他の警告をいじくります。 このコードを直接Nginx HTTP拡張モジュールとして書くことさえ考えていました。 懸念 私の懸念は、これがこれまでに行われたのを見たことがないことであり、より良い方法があるかどうか疑問に思いました。 また、ユーザー固有のコンテンツをページに追加すると、このメソッドは完全に強制終了されます。 Nginxで直接利用できる別の簡単なソリューションはありますか？または、ワニスのようなより専門的なものを使用する必要がありますか？ 私の質問： 上記の解決策は意味がありますか？ これは通常どのように行われますか？ 同様またはより良いパフォーマンスの向上を達成するためのより良い方法はありますか？

9 authentication  caching  nginx 

2つの既存のデータウェアハウスへのアクセスを抽象化する必要があるビジネスインテリジェンスプロジェクトに着手しています。セルフサービスのビジネスインテリジェンスがデータを結合し、2つの既存の倉庫の単一のビューを提供できるように、アプリケーションアーキテクチャを設計する必要があります。私はこのようなものを考え出しました： 私は仮想化/キャッシングの部分に苦労しており、私の問題を解決するためのエンタープライズ設計パターンがあるかどうか疑問に思っています。このようなアーキテクチャは、データウェアハウスのスタースキーマを抽象化するのに役立ちますか？Red Hat JBoss Data VirtualizationやRed Hat JBoss Data Gridなどの製品を探しています。 現在Hibernateを使用しておらず、データグリッドについての私の理解は、それらがキー値ストアまたはオブジェクトストアであるため、リレーショナルモデルのキャッシュには適していません。また、セルフサービスダッシュボードパーツにはベンダー製品を使用したいと考えていますが、ベンダーが必要なすべてを提供できない場合は、この領域でカスタムビルドを実行する可能性があります。

9 architecture  caching 

正しければ、メインメモリのページは、メインメモリとハードディスクなどの外部ストレージデバイスとの間でデータを転送するための最小の単位単位です。メインメモリのキャッシュラインは、メインメモリとCPUキャッシュ間のデータ転送の最小単位です。 ページサイズは常に、またはキャッシュラインサイズの自然数になるのが最適ですか？キャッシュラインサイズが64バイトで、メモリページサイズが4KBの場合、各ページには4KB / 64バイト== 64キャッシュラインがあります。 ページとキャッシュラインはどちらもメモリ内の固定オブジェクトですか？または、特定のサイズのメモリの連続したブロックだけであり、メモリ内のどこにでも開始して浮動させることができますか？ キャッシュラインが複数のページにまたがることは常に可能ですか？つまり、キャッシュラインの一部がページにあり、キャッシュラインの他の部分が別のページにあるのですか？ ありがとう。

9 memory  caching 

のclass XFactoryオブジェクトを作成するファクトリがありますclass X。のインスタンスXは非常に大きいため、ファクトリの主な目的は、クライアントコードに対してできるだけ透過的にインスタンスをキャッシュすることです。のオブジェクトclass Xは不変であるため、次のコードは妥当なようです。 # module xfactory.py import x class XFactory: _registry = {} def get_x(self, arg1, arg2, use_cache = True): if use_cache: hash_id = hash((arg1, arg2)) if hash_id in _registry: return _registry[hash_id] obj = x.X(arg1, arg2) _registry[hash_id] = obj return obj # module x.py class X: # ... それは良いパターンですか？（実際のファクトリーパターンではないことはわかっています。）変更すべき点はありますか？ …

9 design  design-patterns  python  caching  persistence 

私はInnodbのパフォーマンスの最適化に関する記事を読んだことがあります。その投稿では、著者が「バッテリーバックアップキャッシュ」という名前のことについて繰り返し言及していました。彼が何を話していたのか私には明確ではなく、グーグルも助けにはならなかった。私の推測では、これは停電が発生した場合のバックアップストレージのようなものです。私は正しいですか？

8 storage  backups  caching 

このアプローチは、私たちの会社で何かをするために受け入れられている方法です。簡単な例：顧客のデータの一部がサービスから要求された場合、その顧客のすべてのデータ（サービスに関連する部分）をフェッチし、それをメモリ内辞書に保存して、次の要求でそこから提供します（シングルトンサービスを実行します）。更新はすべてDBに送信され、次にメモリ内辞書が更新されます。それはすべて単純で無害に思えますが、より複雑なビジネスルールを実装すると、キャッシュが同期しなくなり、見つけにくいバグに対処する必要があります。時々、データベースへの書き込みを延期し、それまで新しいデータをキャッシュに保持します。テーブルには他のテーブルとの関係が多く、集計データをすばやく表示する必要があるため、数百万の行をメモリに格納する場合があります。 このすべてのキャッシュ処理はコードベースの大きな部分を占めており、これは正しい方法ではないように思います。このすべてのジャグリングはコードに過度のノイズを追加し、実際のビジネスロジックを理解することを困難にします。ただし、毎回データベースにアクセスする必要がある場合、妥当な時間内にデータを提供できるとは思いません。 私は現在の状況に不満を持っていますが、これ以上の選択肢はありません。私の唯一の解決策は、NHibernateの2番目のレベルのキャッシュを使用することですが、これに関する経験はほとんどありません。多くのキャンパニーがパフォーマンスを上げるためにRedisまたはMemCachedを頻繁に使用していることを知っていますが、どのように私たちのシステムに統合するかわかりません。また、メモリ内のデータ構造やクエリよりもパフォーマンスが良いかどうかもわかりません。 検討すべき代替のアプローチはありますか？

8 caching 

ほとんどのWebサイトは、ロゴ画像などの静的アセットmax-age=31536000のCache-controlヘッダーを設定します（1年）。例： YouTube ヤフー ツイッター BBC ただし、注目すべき例外があります。Googleのロゴにはmax-age=6912008日間あります。 私は過去にGoogleロゴのヘッダーを確認しましたが、以前は間違いなく1年でした。（また、以前はスプライトの一部でしたが、現在はスタンドアロンのロゴ画像ですが、おそらく別の質問です...） キャッシュの有効期間をわずか8日間に減らしたいと思う正当な技術的理由は何でしょうか？Googleのホームページは、世界で最も慎重に最適化されたページの1つなので、正当な理由があると思います。 編集： 回答する前に、これらの点を理解しておいてください。 max-age静的アセットを将来変更できるようにするために、短いライフタイムを使用する人はいません。変更する場合は、別のURLで提供するだけです。いいえ、Google Doodleとは関係ありません。考えてみてください。GoogleがこのHTTPの基本的なトリックを理解していなかったとしても、元のロゴがキャッシュされていないユーザーだけがdoodle-dayにDoodleを目にするため、8日間は適切ではありません。そのユーザーグループは、GoogleがDoodleを変更してから8日間、Doodleを見続けていました:) Webサーバーはクライアント（またはプロキシ）のキャッシュを「いっぱいにする」ことを心配していません。クライアントは自分でこれを管理します。自身のストレージ制限に達すると、優先度が最も低いアイテムをドロップし始め、新しいアイテムのためのスペースを作ります。優先度スコアは、「このURLをキャッシュしたことによるメリットはどれくらいありますか？」という質問に基づいています。これはmax-age、URLが最初に要求されたときにサーバーが送信した値とは関係ありません。これは、「頻度」に基づくヒューリスティックです。そのURLに対するリクエストの数です。max-age単にサーバーがカットオフポイントを設定できるようにします。これは、アイテムが再利用される頻度に関係なく、クライアントがアイテムを破棄することになっている時間です。ダウンストリームのクライアント/プロキシがキャッシュをいっぱいにするのを「控え」に頼るのは、とてもいい信頼できることですが、私たちはその世界に住んでいるとは思いません;）

8 caching  http  front-end