Your SlideShare is downloading. ×
0
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Happy Optimization
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Happy Optimization

6,963

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,963
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
40
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Happy Optimization Cybozu Labs, Inc. Kazuho Oku
  • 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. Happy Optimization で重要なこと <ul><li>プロファイラを使うべき </li></ul><ul><ul><li>そんなのは当たり前 </li></ul></ul><ul><li>局所最適化より手前の話をしましょう </li></ul>
  • 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. 続: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. 続: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. 速度の上限について <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. アルゴリズム重要 <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. 速度の壁を突破する方法 <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. 続 : 速度の壁を突破する方法 <ul><li>Lock-free algorithm </li></ul><ul><ul><li>ロックが遅いならロックなしでなんとかすべし </li></ul></ul><ul><ul><li>Cache:: Swifty </li></ul></ul>
  • 11. おしまい <ul><li>Happy Optimization! </li></ul>

×