性能テストで
ボトルネックを探す

「遅い」だけでは、原因は分からない。

大量のGISデータを移行していたとき、 最初に問題になったのは 処理時間の長さでした。

ある程度のデータ量で処理を実行し、 どれくらい時間がかかるのかを確認する。
そして、 その結果をもとに 「このままでは間に合わない」 と判断しました。

ただし、 処理時間が長いという事実だけでは、 どこを直せばいいのか分かりません。

「Pythonの処理が遅い」のか。
「APIへのアクセスが遅い」のか。
「CPUが足りない」のか。
「メモリを使いすぎている」のか。

そこで、 処理時間だけではなく 実行中のシステムの状態を見るようにしました。

まずは処理時間を測る

性能改善を始める前に、 まず必要なのは 現状を数値化することです。

「なんとなく遅い」 という状態では、 改修後に本当に速くなったのか 判断できません。

そのため、 データ量をある程度固定して、 同じ条件で処理を実行します。

開始時刻を記録
        ↓
データ移行処理を実行
        ↓
終了時刻を記録
        ↓
処理時間を比較

重要なのは、 改修前と改修後で条件を揃えることです。

CPUを見てみる

次に確認したのが、 処理実行中のCPU使用率です。

Pythonの処理を並列化すれば、 単純に速くなるようにも思えます。
しかし、 CPUをすでに使い切っている状態で さらに処理を増やしても、 必ずしも速くなるとは限りません。

top

Linuxでは、 top などを使って CPUやメモリ、 実行中のプロセスを確認できます。

ここで見るのは、 単純なCPU使用率だけではありません。

• CPU使用率
• プロセスの状態
• メモリ使用量
• Load Average

こうした情報を処理時間と合わせて見ることで、 「処理が遅い」という現象を もう少し具体的に考えられるようになります。

メモリ使用量も確認する

大量データを扱う処理では、 CPUだけを見ていても 原因が分からないことがあります。

特にPythonでは、 データをメモリ上に保持する処理が多く、 データ量が増えると メモリ使用量も大きくなります。

free -h

さらに、 vmstat などを使うことで、 CPUだけではなく メモリやI/Oなども含めて システムの状態を確認できます。

vmstat

例えば、 処理時間が増えているのに CPU使用率がそれほど高くない場合、 CPU以外の部分に原因がある可能性があります。

そこで、 メモリやI/Oなど、 別の指標を見る必要が出てきます。

ボトルネックを切り分ける

性能テストで重要だったのは、 一つの数字だけを見るのではなく、 複数の情報を組み合わせることでした。

例えば、 CPU使用率が高いのであれば、 CPU負荷の大きい処理が ボトルネックになっている可能性があります。

一方で、 CPU使用率が低いにもかかわらず 処理時間が長い場合は、 API通信やファイルI/O、 待ち時間などを疑う必要があります。

このように、 「何が遅いのか」を切り分ける ことが性能改善の最初の一歩になります。

並列化すれば速くなるのか

大量データを処理する場合、 一つずつ順番に処理するより、 複数の処理を同時に実行したほうが 速くなる可能性があります。

そこで、 Pythonの並列処理について調べ、 実際の処理に取り入れていきました。

処理A ────────→
処理B ────────→
処理C ────────→

        ↓

複数処理を同時に実行

ただし、 並列数を増やせば増やすほど 無条件に速くなるわけではありません。

CPU、 メモリ、 API側の負荷、 ネットワーク、 同時接続数など、 さまざまな制約があります。

改修したら、もう一度測る

性能改善では、 一度改修して終わりではありません。

実際には、

調べる。
試す。
測る。
改修する。
また測る。

という繰り返しになります。

例えば、 並列処理を導入した場合は、 導入前と導入後で 処理時間を比較します。

さらに、 処理時間だけではなく CPUやメモリの状態も確認します。

性能テストで分かったこと

この経験を通して、 性能問題は 「コードの一部分を速くする」 だけでは解決できないことを 実感しました。

Pythonのコードを見る。
↓
データ量を見る。
↓
CPUを見る。
↓
メモリを見る。
↓
APIやI/Oを見る。
↓
もう一度テストする。

こうやって一つずつ確認していくことで、 最初は単純に 「処理が遅い」 としか見えていなかった問題が、 少しずつ具体的な問題として 見えるようになりました。