エキPy読書会 16 (2011/8/2)¶
- 日時:
2011/8/2 20:00 - 22:00
- 範囲:
第12章(p321~): 最適化:一般原則とプロファイリングテクニック
エキスパートPythonプログラミングの読書会16回目。
最適化のためのプロファイリングについて。
事前に出た質問¶
Q: Munin (http://munin-monitoring.org/) とはどういうツールですか?
A: RRDTool を使った状態監視ツールです。MRTG や cacti (カクタイ) と良く似たツールです。最近だと cacti の方がよく使われている気がします。
Q: timeit でベンチマークを取るのが面倒なのですが、もうちょっと良い方法はありますか?
A: IPython から timeit を使うと少し便利です。
Q: スレッドの協調動作を profile/cProfile で計測できますか?
A: パフォーマンスを上げる目的なら 2.6 以降から multiprocessing を使えるようになったので協調型スレッドのプロファイルを計測したことがない
Q: Perl の AnyEvent のようなノンブロッキングフレームワークは Python にないの?
A: Python だと greenlet や gevent に相当するのかな、稲田さんに聞きたい
Q: みなさんが用いている最適化手法
A: まずプロファイリングしましょう。ボトルネックを探し出すのは地道な作業になる。無駄なループ処理を外へ出したり、よく使う値はキャッシュしたり、multiprocessing でマルチプロセスで処理を分散したりで行う
Q: Web アプリで DB が関連する処理のプロファイルはどうする?
A: DB は遅いので RDB/KeyValue やキャッシュをどう使うかを検討する、WSGI プロファイルでページ単位での時間を計測したりできる、ピュア Python の処理部分、ネットワークやデータベースといった大きな単位でまずプロファイルを取ってから切り分けする
Q: JavaScript のプロファイルはどうする?
A: Firefox のアドオンで計測する、 WebKit を内包したツールを用いてヘッドレステストをする? これかな? http://shigeya.org/blog/archives/2011/05/rspec-capybara-webkit.html
Q: おすすめツール群
A: 本章で紹介されたツール、その他は pip search で探してください。
Q: 皆さんが遭遇した問題?と解決方法(どんな題が発生してどう解決したかなど)
A: アルゴリズムの改良を地道にやる、 処理のオーダーが現実的なのに速度が出ないならハードを購入する方がコストパフォーマンスにあう場合もある、 まずはアルゴリズムのオーダーをきちんと計算しないと費用対効果が分からない、 OSS だと、遅いとイライラするからチューニングすることもある
Q: そもそもPythonで速度とか求められるアプリを書くんでしょうか?
A: 過去に秒間5,000アクセスのリクエストを 1CPU で処理するサーバーを実装しました
Q: プロファイリングの仕方とチューニングポイントの見つけかた。
A: チューニンガソンの稲田さんのブログ、考え方の参考になる
Q: DB が関連する処理のチューニングはどうする?
A: マスタデータが数百件ならメモリにもってしまった方が SQL のクエリを減らせて速くなるこもとある、インターフェースも含めたプロファイルを取ってみてから、遅ければ SQL チューニングを行うこともある
Q: CPython や Jython や IronPython のパフォーマンスはどうなの?
A: いま一番速いのは PyPy らしい、次が CPython PyPy はループ処理が高速だが、再帰が遅くなるようにみえる 実用を考えると、PyPy は CPython との非互換があったり、C 拡張モジュールが未対応だったりする、 日増しによくなっているので近いうちに完全対応するかもしれません
参考¶
Togetter: http://togetter.com/li/170026