Happy Optimization

Happy Optimization Cybozu Labs, Inc. Kazuho Oku

昨日 Pathtraq API 公開しました
6000 万 URL のアクセス統計をマッシュアップ可能
よろしくお願いします
というのは、さておき… 最適化の話。

Happy Optimization で重要なこと
プロファイラを使うべき
そんなのは当たり前
局所最適化より手前の話をしましょう

続：Happy Optimization で重要なこと
「 30% 速くなったよ」
これはダメなパターン ( きりがない )
永遠にずるずる続けてしまう
投入する開発コストを回収できるかが問題

処理速度には必ず上限があるはず
例 : MIPS, バンド幅 , アクセスタイム
「理論上の最速値の 70% に到達」
これが良いパターン
最適化コストの回収可能性が事前に評価できる

lang/sql/mysql_timeline
このケースでの上限は 2,600QPS 程度 (P4@3GHz)
SQL やストアドでがんばってもダメ
だったら UDF
2,000QPS 出た->あと 600QPS のために頑張るか ?
2,000 UDF 136 ストアドプロシージャ 56.7 SQL タイムライン / 秒

速度の上限について
どうやって予測するか
mysql_timeline の場合は、プッシュモデルの値
一般的には IPC のコストがボトルネック
ソケット通信だと 100k transaction / sec. くらい
サーバ内の処理をケチってもメリットは少ない
1,000 clks/tr 〜 97k tr/sec. (3GHz の CPU を想定 )
5,000 isns/tr 〜 86k tr/sec.
数値は適当です (^^;
あまりサーバを単純化してもメリットは小さい

アルゴリズム重要
とは言え C10k だとアルゴリズム重要
例 : サーバ内の接続は array[fd] で管理可能
file descriptor は常に空いている最小値が採用される
リンクリストの管理 / 空きスロットの探索が不要に
lang/perl/fastr , lang/cplusplus/friends_framework , KeyedMutex
接続を array[fd] で管理
タイムアウト処理は ring_buffer_of_bit_vector[at][fd]
と言っても限界はあるわけで…

速度の壁を突破する方法
SIMD (SSE)
Instruction per second が足りないなら、ベクタ演算
lang/cplusplus/range_coder
圧縮
HDD のバンド幅が足りないなら、圧縮すべし
lang/cplusplus/range_coder
グループコミット
HDD への書込が遅いなら、まとめて書き込むべし
Q4M

続 : 速度の壁を突破する方法
Lock-free algorithm
ロックが遅いならロックなしでなんとかすべし
Cache:: Swifty

おしまい
Happy Optimization!

http://developer.cybozu.co.jp	1553
http://labs.cybozu.co.jp	502
http://webcache.googleusercontent.com	18
http://74.125.153.132	3
http://www.modiphi.com	2
http://www.slideshare.net	2
http://trf.happy-camper.st	1
http://r.hatena.ne.jp	1

Happy Optimization

by kazuho on Jul 24, 2008

Accessibility

Tags

Upload Details

Usage Rights

8 Embeds 2,082

Statistics

Happy Optimization — Presentation Transcript