Happy Optimization
Upcoming SlideShare
Loading in...5
×
 

Happy Optimization

on

  • 1,032 views

 

Statistics

Views

Total Views
1,032
Views on SlideShare
1,030
Embed Views
2

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Happy Optimization Happy Optimization Presentation Transcript

  • Happy Optimization Cybozu Labs, Inc. Kazuho Oku
    • 昨日 Pathtraq API 公開しました
      • 6000 万 URL のアクセス統計をマッシュアップ可能
      • よろしくお願いします
    • というのは、さておき… 最適化の話。
  • Happy Optimization で重要なこと
    • プロファイラを使うべき
      • そんなのは当たり前
    • 局所最適化より手前の話をしましょう
  • 続:Happy Optimization で重要なこと
    • 「 30% 速くなったよ」
      • これはダメなパターン ( きりがない )
      • 永遠にずるずる続けてしまう
    • 投入する開発コストを回収できるかが問題
  • 続:Happy Optimization で重要なこと
    • 処理速度には必ず上限があるはず
      • 例 : MIPS, バンド幅 , アクセスタイム
    • 「理論上の最速値の 70% に到達」
      • これが良いパターン
      • 最適化コストの回収可能性が事前に評価できる
  • 続:Happy Optimization で重要なこと
    • 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!