Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Happy Optimization

7,790 views

Published on

  • Be the first to comment

Happy Optimization

  1. 1. Happy Optimization Cybozu Labs, Inc. Kazuho Oku
  2. 2. <ul><li>昨日 Pathtraq API 公開しました </li></ul><ul><ul><li>6000 万 URL のアクセス統計をマッシュアップ可能 </li></ul></ul><ul><ul><li>よろしくお願いします </li></ul></ul><ul><li>というのは、さておき… 最適化の話。 </li></ul>
  3. 3. Happy Optimization で重要なこと <ul><li>プロファイラを使うべき </li></ul><ul><ul><li>そんなのは当たり前 </li></ul></ul><ul><li>局所最適化より手前の話をしましょう </li></ul>
  4. 4. 続:Happy Optimization で重要なこと <ul><li>「 30% 速くなったよ」 </li></ul><ul><ul><li>これはダメなパターン ( きりがない ) </li></ul></ul><ul><ul><li>永遠にずるずる続けてしまう </li></ul></ul><ul><li>投入する開発コストを回収できるかが問題 </li></ul>
  5. 5. 続:Happy Optimization で重要なこと <ul><li>処理速度には必ず上限があるはず </li></ul><ul><ul><li>例 : MIPS, バンド幅 , アクセスタイム </li></ul></ul><ul><li>「理論上の最速値の 70% に到達」 </li></ul><ul><ul><li>これが良いパターン </li></ul></ul><ul><ul><li>最適化コストの回収可能性が事前に評価できる </li></ul></ul>
  6. 6. 続:Happy Optimization で重要なこと <ul><li>lang/sql/mysql_timeline </li></ul><ul><ul><li>このケースでの上限は 2,600QPS 程度 (P4@3GHz) </li></ul></ul><ul><ul><ul><li>SQL やストアドでがんばってもダメ </li></ul></ul></ul><ul><ul><ul><li>だったら UDF </li></ul></ul></ul><ul><ul><ul><li>2,000QPS 出た->あと 600QPS のために頑張るか ? </li></ul></ul></ul>2,000 UDF 136 ストアドプロシージャ 56.7 SQL タイムライン / 秒
  7. 7. 速度の上限について <ul><li>どうやって予測するか </li></ul><ul><ul><li>mysql_timeline の場合は、プッシュモデルの値 </li></ul></ul><ul><li>一般的には IPC のコストがボトルネック </li></ul><ul><ul><li>ソケット通信だと 100k transaction / sec. くらい </li></ul></ul><ul><ul><ul><li>サーバ内の処理をケチってもメリットは少ない </li></ul></ul></ul><ul><ul><ul><ul><li>1,000 clks/tr 〜 97k tr/sec. (3GHz の CPU を想定 ) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>5,000 isns/tr 〜 86k tr/sec. </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>数値は適当です (^^; </li></ul></ul></ul></ul></ul><ul><ul><li>あまりサーバを単純化してもメリットは小さい </li></ul></ul>
  8. 8. アルゴリズム重要 <ul><li>とは言え C10k だとアルゴリズム重要 </li></ul><ul><ul><li>例 : サーバ内の接続は array[fd] で管理可能 </li></ul></ul><ul><ul><ul><li>file descriptor は常に空いている最小値が採用される </li></ul></ul></ul><ul><ul><ul><li>リンクリストの管理 / 空きスロットの探索が不要に </li></ul></ul></ul><ul><ul><li>lang/perl/fastr , lang/cplusplus/friends_framework , KeyedMutex </li></ul></ul><ul><ul><ul><li>接続を array[fd] で管理 </li></ul></ul></ul><ul><ul><ul><li>タイムアウト処理は ring_buffer_of_bit_vector[at][fd] </li></ul></ul></ul><ul><li>と言っても限界はあるわけで… </li></ul>
  9. 9. 速度の壁を突破する方法 <ul><li>SIMD (SSE) </li></ul><ul><ul><li>Instruction per second が足りないなら、ベクタ演算 </li></ul></ul><ul><ul><li>lang/cplusplus/range_coder </li></ul></ul><ul><li>圧縮 </li></ul><ul><ul><li>HDD のバンド幅が足りないなら、圧縮すべし </li></ul></ul><ul><ul><li>lang/cplusplus/range_coder </li></ul></ul><ul><li>グループコミット </li></ul><ul><ul><li>HDD への書込が遅いなら、まとめて書き込むべし </li></ul></ul><ul><ul><li>Q4M </li></ul></ul>
  10. 10. 続 : 速度の壁を突破する方法 <ul><li>Lock-free algorithm </li></ul><ul><ul><li>ロックが遅いならロックなしでなんとかすべし </li></ul></ul><ul><ul><li>Cache:: Swifty </li></ul></ul>
  11. 11. おしまい <ul><li>Happy Optimization! </li></ul>

×