まず、可能であれば、データをクライアント側に保存するのが最善かもしれません。これにより、作業がはるかに楽になります。データベースへの保存またはディスクへの書き込みも有効なオプションですが、データベースは同時にアクセスするように設計されているのに対し、個々のファイルはそうではないことに注意してください。そのため、ストレージ メカニズムを慎重に設計する必要があります。
一部のサーバーは、リソースを節約するために、アイドル状態のプロセスを自動的に強制終了するように構成されています。確実にそうであるとは言えませんが、httpd 構成で WSGIDaemonProcess の次の設定を確認してください。
maximum-requests=nnn
デーモン プロセスがシャットダウンして再起動する前に処理する必要がある要求の数の制限を定義します。これをゼロ以外の値に設定すると、(偶発的な) メモリリークによってプロセスが消費できるメモリの量を制限できるという利点があります。
このオプションが定義されていないか、0 に定義されている場合、デーモン プロセスは永続的であり、Apache 自体が再起動またはシャットダウンされるまでリクエストを処理し続けます。
inactivity-timeout=sss (2.0+)
デーモン プロセスがアイドル状態になったときに、デーモン プロセスがシャットダウンされて再起動されるまでの最大許容秒数を定義します。このオプションの目的上、アイドル状態とは、新しいリクエストが受信されていないこと、または現在のリクエストによるリクエスト コンテンツの読み取りまたはレスポンス コンテンツの生成が定義された期間試みられていないことを意味します。
このオプションは、デーモン プロセスで実行されている使用頻度の低いアプリケーションを再起動できるようにするために存在します。これにより、使用中のメモリを再利用できるようになり、プロセス サイズは、アプリケーションがロードされる前または要求が処理される前の初期の起動サイズに戻ります。
デッドロックタイムアウト=sss (2.0+)
Python GIL でデッドロックの可能性が検出された後、デーモン プロセスがシャットダウンされて再起動されるまでの最大許容秒数を定義します。デフォルトは 300 秒です。
このオプションは、ブロッキングまたは長時間実行される操作に入ったときに Python GIL を適切に解放しない不正な Python C 拡張モジュールの結果として、デーモン プロセスがフリーズする問題に対処するために存在します。
シャットダウンタイムアウト=sss
要求の最大数または非アクティブ タイムアウトに達した結果としてデーモン プロセスが正常にシャットダウンするのを待機するとき、またはユーザーが開始した SIGINT シグナルがデーモン プロセスに送信されるときに、経過できる最大秒数を定義します。このタイムアウトに達すると、アクティブなリクエストがまだ存在するか、まだ Python の終了機能を実行している場合でも、デーモン プロセスは強制的に終了されます。
このオプションが定義されていない場合、シャットダウン タイムアウトは 5 秒に設定されます。このオプションは、Apache 自体の停止または再起動時にデーモン プロセスに適用されるシャットダウン タイムアウトを変更しないことに注意してください。このタイムアウト値は Apache に対して内部的に 3 秒として定義されており、オーバーライドすることはできません。
ソース: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives