• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Happy Optimization
 

Happy Optimization

on

  • 1,013 views

 

Statistics

Views

Total Views
1,013
Views on SlideShare
1,011
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!