私は、Python/mod_wsgiを実行しているWebファームで高速キャッシュを作成するためのさまざまなシステムを検討してきました。私は、ローカルキャッシュを維持するために、各マシンを望む、マシン間でデータを共有する必要がないのでんPythonやWSGIが提供 Python/mod_wsgiサーバーのグローバルデータ
...を：Memcacheの他はオプションです...しかし、私は思っていましたサーバーが再起動されるまで、データが持続してすべてのスレッド/プロセスが利用できるように、ApacheのPythonネイティブ共有データ用のメカニズム？このようにして、実行中のすべてのアプリケーションインスタンスのメモリ空間に並行性制御を持つオブジェクトのキャッシュを保持できますか？
ない場合、それは確かに
おかげで有用であろう！
Djangoのスレッドセーフなメモリ内キャッシュバックエンドについては、hereを参照してください。これはcPickleベースで、Djangoで使用するように設計されていますが、Djangoの残りの部分には最小の依存関係があり、簡単にリファクタリングして削除することができます。明らかに、各プロセスはスレッド間で共有される独自のキャッシュを取得します。同じマシン上のすべてのプロセスがキャッシュを共有したい場合は、独自のプロセスでこのキャッシュを任意のIPCインターフェイス（ドメインソケット）と組み合わせて使用するか、ローカルでmemcachedを使用するか、再起動の際にthisのようなPythonインタフェースを持つTokyo Cabinetのようなものです。
これは、mod_wsgiドキュメントのSharing and Global Data sectionによって完全に網羅されています。短い答えは：いいえ、1つのプロセスですべてを実行しない限り、それは理想的な解決策ではありません。
memcacheを含む複数のバックエンドをサポートするcaching is ridiculously easy to do with Beaker middlewareに注意してください。
+1 ...面白く見える、ピークを取る –
これは古いスレッドだとわかりましたが、ここでは "サーバー全体のdict"の別のオプションがあります：http://poshmodule.sourceforge.net/posh/html/posh.html（POSH、Python Shared Objects）。免責事項：それはまだ自分自身を使用していない。
+1 ...よく見えますが、cPickleはかなり遅いと思われますか？ –
おそらく起動して実行するのが簡単なので、ベンチマークしてニーズに合っているかどうかを確認できます。明らかに、すべてのPython-to-Pythonが同じプロセスであれば、エントリのシリアル化を気にする必要はありません。それは単にキャッシュ有効期限ポリシーを持つ大きなディクテーションのように機能します。 –
ああ、ちょうどサーバー全体のdictは本当に後でIm何ですか？ –