Performance@Scale雑感

少し前、なぜかPerformance@ScaleというFacebook主催のカンファレンスのinvitationをゲットできたので、行って聴講してきた。直接の仕事にはあんまり関係ないけど、どうやって高いパフォーマンスを実現できるのか、測定できるのか、といったテーマの話で、なかなか面白い話が多かった。

動画などが https://code.facebook.com/posts/997355933686556/performance-scale-2016-recap/ でまとめられているから見ると面白いと思う。

個人的に面白いと思ったのはパフォーマンスリグレッションの特定の話（Automatic regression triaging at Facebook）。実際のサーバについて様々な性能（応答時間とか）をグラフ化しておくと、まあ実際にはガタガタしているわけだけれども、うまいこと定義を作ればパフォーマンスが悪化したタイミングを捕まえることができる。これはまあ普通。で、その悪化したタイミングに変更を行った人にアラートを送って直してね、っていう。これもまあ普通だよね。

で、面白いのは、このスピーカーはfacebookの人なわけだけど、現実にはプッシュのタイミングは1日1回とか数回に限られるので、悪化したタイミングと言っても数百、数千といった変更が候補になってしまって、意味がないと。なのでこれをどう自動的に絞り込むかが鍵となる。でどうするかというと、悪化したパターンのコールスタックを取り、コールグラフからパフォーマンスに影響のある関数を特定して、その関数やコールスタックに影響のある変更に絞り込んで云々、というもので、なるほど面白い。まあこの問題がだいじになる世界というのはそれほど多くはないだろうけれど。

—

もうひとつ、Facebookのウェブパフォーマンスの話で、ストーリー自体は基本を押さえたものだと思うけれど、Facebook内のコードスニペットがとても面白かった。

というのは、PHPではなくてHackのコードスニペットな訳だけど、Hackこんなんなのか！というので驚いた。PHPに型注釈をつけたもの、というのが私の荒い理解だったのだけれど、さすがに荒すぎであった。

  • async/awaitなんてあるんかい
  • Awaitable<>のようなパラメトリック型
  • ScalaのようにHTMLの断片をコードに直接書けて、これがReactと統合されててReact DOMのオブジェクトになるらしい

などなど……Hack思ったより遥かに進化しているし、FacebookはもうPHPじゃないのかもなあと思ったのだった。

—

Facebook以外だと冒頭のBrendan Greggの話や、Chromiumのヒストグラムを解説するJim Roskindなどは面白かった。

Brendan Greggはかつてdtraceを開発していた筋金入りのパフォーマンスエンジニアで、話も面白かったのだが、「１０年前もdtraceの話をして……それからキャンパスはだいぶ変わったけれど、トピックや解析の内容は変わっていない」っていう冒頭のつかみ、あとで雑談していて気づいたけど、Brendanはまさにそのころ、会場のFacebookキャンパスのあった場所にあったSUNで働いていてdtraceを開発していたっていう話だったのだなあ。時の流れに思いを馳せたりした。