簡単な 1 回限りの改善は、長期間有効なスクリプトとデーモンに標準の CPython の代わりにPyPyを使用することです (有効期間が短いスクリプトの場合は、役に立たない可能性が高く、実際には起動時間が長くなる可能性があります)。それ以外では、短命のシステム スクリプトの最大の改善点の 1 つにすでに気付いているようです。これは、頻繁に呼び出されるスクリプトの Python インタープリターを起動するオーバーヘッドを回避することです。
たとえば、あるスクリプトを別のスクリプトから呼び出し、それらが両方とも Python である場合は、subprocessまたは類似のものを使用するのではなく、他のスクリプトをモジュールとしてインポートし、その関数を直接呼び出すことを検討する必要があります。
一部のユースケースは外部スクリプトの呼び出しに依存しているため、これが常に可能であるとは限らないことを理解しています-たとえば、Nagiosチェックは常に常駐しておくのが難しいでしょう. 実際のチェック スクリプトを単純な HTTP リクエストにするというあなたのアプローチは十分に合理的と思われますが、私が取ったアプローチは、パッシブ チェックを使用し、外部サービスを実行して定期的にステータスを更新することでした。これにより、チェック結果を生成するサービスをデーモンとして常駐させることができ、チェックごとに Nagios にスクリプトを呼び出す必要がなくなります。
また、システムを監視して、遅さの原因が本当に CPU の過負荷なのか IO の問題なのかを確認してください。vmstatIO の使用状況を監視するようなユーティリティを使用できます。IO に縛られている場合、コードを最適化しても必ずしもあまり役に立ちません。この場合、大量のテキスト ファイル (ログ ファイルなど) を処理するようなことをしている場合は、それらを gzip 形式で保存し、Python のgzipモジュールを使用して直接アクセスできます。これにより、CPU 負荷が増加しますが、圧縮されたデータをディスクから転送するだけで済むため、IO 負荷は減少します。同じアプローチを使用して、出力ファイルを gzip 形式で直接書き込むこともできます。
特に詳しいweb2pyことはわかりませんが、データの鮮度がそれほど重要でない場合は、キャッシング レイヤーを前面に配置するのが簡単かどうかを調べることができます。サーバーとクライアントの両方が条件付きリクエストを正しく使用していることを確認してください。これにより、リクエストの処理時間が短縮されます。バックエンド データベースを使用している場合は、memcachedのようなものが役立つかどうかを調べることができます。これらの対策は、かなり大量のリクエストが発生している場合、または各リクエストの処理にコストがかかる場合にのみ、真のメリットをもたらす可能性があります。
また、一般的にシステム負荷を他の方法で軽減すると、驚くべき利点が得られる場合があることも付け加えておく必要があります。以前は比較的小規模なサーバーで Apache を実行していましたが、nginx に移行することで驚くほど効果があることがわかりました。部分的にはリクエスト処理の効率が向上したと思いますが、主に、ファイルシステム キャッシュが IO をさらにブーストするために使用できるメモリの一部が解放されました。バインドされた操作。
最後に、オーバーヘッドがまだ問題である場合は、最も高価なスクリプトを慎重にプロファイリングし、ホットスポットを最適化します。これにより、Python コードが改善される可能性があります。また、オプションである場合は、コードを C 拡張機能にプッシュすることを意味する可能性もあります。大規模なログ処理や同様のタスク (一度に数百 GB のログを扱う) のためにデータパス コードを C 拡張機能にプッシュすることで、優れたパフォーマンスが得られました。ただし、これは手間がかかり、時間のかかるアプローチであるため、速度の向上が本当に必要ないくつかの場所に限定する必要があります。また、C に十分精通した人が利用できるかどうかにもよります。