問題タブ [django-cache]

ページが本番サーバーと開発サーバーのキャッシュからのものであることを確認する方法はありますか?

すべてのプロジェクトでミドルウェアが使用されているわけではないため、解決策にキャッシング ミドルウェアを含めるべきではありません。ソリューション自体はミドルウェアかもしれませんが。

データが古いかどうかを確認するだけでは、IMO の安全なテスト方法とは言えません。

memcached を使用して django ビューをキャッシュすることをテストしています。memcached が実際に Linux コマンド ラインから何かをキャッシュしているかどうかを確認するにはどうすればよいですか?

私は小さなプロジェクトに取り組んでおり、エンド ユーザーに複数のキャッシュ オプションを提供したいと考えていました。Django では、memcached をデータベースまたはファイル ベースのキャッシュに交換するのは非常に単純であると考えました。私の memcached 実装は、問題なくチャンピオンのように機能します。ページにタイム スタンプを配置しました。curl は、キャッシュを適切に機能させたい場所で一貫して古いタイムスタンプを表示します。しかし、データベース キャッシングに切り替えると、データベースにエントリがまったく取得されず、キャッシングが露骨に機能しません。

ドキュメントで見たところ、必要なのはバックエンドを次のように変更することだけです。

に：

必要な manage.py (createcachetable) 行を実行した後にテーブルが存在し、問題なく表示できます。私は現在テスト中なので、sqlite3 を使用していますが、私が知る限り、それは問題ではありません。テーブルが完全に空であり、どの時点でも書き込まれていないことを確認できます。また、前に述べたように、タイムスタンプも「間違っている」ため、何かが正しくないというより多くの証拠が得られます。

何かご意見は？現在Ubuntu JauntyマシンでApache経由でサービスを提供しているsqlite3、Django 1.0.2、python 2.6を使用しています。私は単純なものをただ見ているだけだと確信しています。助けてくれてありがとう。

私は Google App Engine で Django (1.0.2) を実行しています。次のDjango キャッシュ モジュールのうち、 Google の memcache実装で本質的に動作する必要があるもの (存在する場合) を知りたいです。

ミドルウェア

• django.middleware.cache.UpdateCacheMiddleware

• django.middleware.common.CommonMiddleware

• django.middleware.cache.FetchFromCacheMiddleware

デコレータ

• django.views.decorators.cache.cache_page

テンプレート フラグメントのキャッシュ

テンプレートでは:

低レベル API

• django.core.cache

これらのモジュールの一部またはすべてが機能する場合、それらを適切に機能させるために必要な変更はありますか? また、モジュールを使用する際に注意すべき懸念事項や落とし穴はありますか?

ドキュメントを熟読し、Google で検索するのに時間を費やしましたが、これに対する答えは見つかりませんでした。「ターンキー」ソリューションである可能性があると思いますが、他の誰かが問題なくそれを行ったという参照が少なくとも1つない状態でDjangoクラスを使用することには注意が必要です。

よろしくお願いします。

サイドバーに入れたい小さなスニペットがあります。スニペットは各ページに表示され、安価に取得できますが (私の非常に遅いネットブックでは約 50 ミリ秒です!)、あまり頻繁に変更されないため、キャッシュしたいと思います (部分的には、まだ Django のキャッシュを使用したことがないためです)。フレームワーク、そして私は学びたいです）。

ここに行く最善の方法がわかりません-ミドルウェアまたはカスタムテンプレートタグ? これらのアプローチでキャッシングを実装するのがどれほど簡単かはわかりません。これは、実行したい非常に標準的なこと (つまり、各ページに表示されるフラグメントのフラグメント キャッシュ) であるため、Djangonicの方法があると確信していますが、それが何であるかを見つけることができません。

どのようにしますか？

私は、ユーザーがシステム上で何かを行うための適切な権限を持っていることを確認するために、ビューに対して12ほどの権限ルックアップを持っています（つまり、ユーザーがプロファイルを編集できる場合、グループ管理者である場合は、適切なグループに属していることを確認してください。等）。

チェックは次のようになります。

これは実際にはDjangoチュートリアルのコードです（私のものは少し醜いです）。チェックはデータベースを非常に集中的に使用し、複数のクエリを実行する場合があります。多くのユーザーが権限がチェックされたページを押すと、物事はすぐに非常に遅くなる可能性があります。

'TESTCACHE' + user.pk + 'testname'私の質問は、（あなたの助けを借りて）キャッシュでキーを検索し、キーが存在しない場合はテストを実行してその結果を保存するuser_passes_testデコレータのラッパー（または置換）を構築できますか？

私はこれまでデコレータを書いたことがありませんがuser_passes_test、文字列としてテストに合格するだけで、デコレータとほぼ同じに見えると思います。

そしていつものように、私が怒っているかどうか、またはDjangoがすでにこれを行っているかどうかを知らせてください（他の場所で問題が発生しています）。

編集：標準のデコレータはここにあります：http：//code.djangoproject.com/browser/django/trunk/django/contrib/auth/decorators.py

user_passes_test包むより交換する方が簡単かもしれないと思うので、ここから始めます。もちろん、その声明で私が間違っていると感じた場合は、私に知らせてください。

memcached で 1 MB よりも大きなデータを保持するためのソリューションについて知っている人はいますか?

大きなデータを設定する前に 1 MB の断片にカットし、memcached から取得した後にこの断片をマージするのは大したことではありません。また、このアルゴリズムはユーザーに対して透過的に機能します。

これは、このスニペットhttp://www.djangosnippets.org/snippets/488/のベースで機能します

ビューだけでなく、任意のメソッドにリクエストごとのキャッシュを提供するデコレータを実装したいと思います。使用例を次に示します。

レコードの長いリスト内のレコードが「お気に入り」かどうかを判断するカスタム タグがあります。アイテムがお気に入りかどうかを確認するには、データベースにクエリを実行する必要があります。理想的には、1 つのクエリを実行してすべてのお気に入りを取得し、キャッシュされたリストを各レコードに対してチェックするだけです。

1 つの解決策は、ビュー内のすべてのお気に入りを取得し、そのセットをテンプレートに渡し、次に各タグ呼び出しに渡すことです。

あるいは、タグ自体がクエリ自体を実行することもできますが、それは最初に呼び出されたときだけです。その後、後続の呼び出しのために結果をキャッシュできます。利点は、ビューに警告することなく、任意のビューで任意のテンプレートからこのタグを使用できることです。

既存のキャッシュ メカニズムでは、結果を 50 ミリ秒だけキャッシュし、それが現在の要求に相関すると想定できます。その相関関係を信頼できるものにしたい。

これは私が現在持っているタグの例です。

Django から現在のリクエスト オブジェクトを取得する方法はありますか? タグから、常に存在するリクエストを渡すだけで済みます。しかし、他の関数からこのデコレータを使用したいと思います。

リクエストごとのキャッシュの既存の実装はありますか?

私はユーザーが2つのインターフェースモードから選択できるDjangoアプリを持っています、そのモードはいくつかのページに影響を与えます...それらのページのために私は異なるテンプレートを使用します

urls.pyには、次のようなものがあります。

次に、私の見解は次のようなものです。

私の問題は、ユーザーがモード2を選択した場合（カスタム構成ページで）、サーバーが再起動されるまでモードが変更されないことです（apacheまたはrunserver.pyのいずれかが同じです）。

これはキャッシュと関係があると思いますが、そのキャッシュを消去する方法が見つかりません。（Config.modeが変更されるたびに。）

いくつかのテンプレート内でhtmlをキャッシュしています。

低レベルライブラリを使用してキャッシュにアクセスできますか? 例えば

テンプレートのキャッシュを細かく制御する必要があります:)

何か案は？みんな、ありがとう！:D