1. Happy Optimization Cybozu Labs, Inc. Kazuho Oku

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

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

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

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

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

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

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

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

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

11. おしまい Happy Optimization!