RubyKaigi 2016 3日目メモ #rubykaigi

rubykaigi.org

raydive.hatenablog.jp

raydive.hatenablog.jp

引き続き最終日も参加してきました。"Deletion Driven Development: Code to delete code!"でのエッジケース乱舞は本当につらい案件であり、入らないコードはざくざく削除していこうと思いました。ちなみにC#で似たようなことをしたことありますね……あとHTTP/2の話は非常に勉強になった。

Web Clients for Ruby and What they should be in the future

  • Toru Kawamura
  • Rubyで書かれたWeb APIにアクセスする人が操作するクライアントを対象
  • ほしくないクライアント
    • 簡単に変更できない
    • 再利用できない
  • 今のgem
    • ドキュメントからgemを作成
      • API変わると作り直し
    • ドキュメントに変更を書くのではなくAPIのレスポンスに書くと対応できる
  • 疎結合なクライアント
    • URLをハードコードせず、リンクをたどる
  • Web APIは簡単
    • net/httpとかつかってる?
      • 他に使っている
    • Web API gemいっぱいあるよね
      • 一長一短
      • 提供する側からだとどうか?
        • インタフェースの再設計
        • 複数言語の対応は大変
      • なんでいっぱいある?
        • レスポンスのJSONの構造の違い
        • 行いたい処理とAPI一回の動きのギャップ
  • Web APIでの状態管理
    • クライアントが状態管理してしまえばいいと思っている
  • ほしいWeb Clientsは状態管理できるもの
  • サーバ側のrackみたいにクライアント側も決めごとがあればいいかなぁ
    • Faradayがあった
    • Rack Middlewareのような形を採用している
    • gemでつくるのではなくFaraday Middlewareでつくるのが再利用もしやすいのではないだろうか
  • gemを作った
    • faraday-navigatoin
      • back/forward
      • リンクをたどる
        • RFC5988
        • RFC6570
    • faraday-link-extractor
      • リンクを抽出してLink/Link-Template headerに変換する

Deletion Driven Development: Code to delete code!

Deletion Driven Development: Code to delete code! - RubyKaigi 2016

  • Chris Arcand
  • コードを殺す方法w
  • コード書くのも好きだけど、削除するのが好き
  • Dead
    • over engineering
    • poorly written
    • refactoring
  • 誰がめんどうみるの?
    • deleting code 2002
      • コードのノイズは開発者の大敵
  • どうやって削除するコードみつける?
    • その方法
  • .rb => ???
    • 静的なチェック
    • parsing the code
      • CFG
      • BNF
        • 解析してルールにあわないものをはじく
      • Rubyだとどうする?
        • ruby_parcerでパース
    • Processing the s-experession
      • S式からメソッドがどこで定義されてるか洗い出す方法
    • Find deleting method
      • sendでメソッドコールすると見逃す
        • S式で判断
      • attr_accessorが見逃されてる
        • これもエッジケース
  • Rubyは難しい
    • エッジケースある
  • Rails DSL
    • エッジケースおおすぎ……
  • gemあり
  • debride以外もいろいろある
  • メソッドが相互に呼んでる場合は検知できる?
    • できない?
  • Railsのunused actionは検知できる?

Recent Advances in HTTP and Controlling them using ruby

  • Kazuho Oku
  • Current State of http
    • なんでhttp2か?
      • レイテンシがボトルネック
      • http2ではconcurrencyでレイテンシを隠蔽
    • 2015/5 released
      • 全体の3割がhttp2
    • http2 feature
      • header圧縮
        • positiveな結果 中央値で90%データ削減
      • 多重化&優先順位漬け
      • push
        • positive&negative
          • pushしたものの5割が無駄
  • 問題点をどうやってfixするか?
    • 理想 => 優先順位が高いリクエストに早く返す、リソースを正しい順序で返す、ないデータをpushする
    • どれもできてない
  • head of line blocking
    • 優先度の高いデータがあるけど低いデータが滞留しているのでおくれない
    • 技術的に解決できそう
      • 実装して評価
        • 理想的な最適化を得られる
  • 優先順位漬け
    • クライアント側で提示、サーバで参考にして送る
    • CSSJavascriptが帯域のほとんどをしめる
    • SafariやBlinkは優先順位漬けしてくれない
      • 画像が帯域をしめてしまう => HtmlやCSS, Javascriptが後回し => 表示が遅くなる
    • バンド幅の正しいわりふり
      • WFQやDRRを使ってスケジューリング
        • nghttp2とかH2OはWFQを実装
      • 頭の悪そうなクライアントにはCSSJavascriptを先に送信する
  • hidden resource
    • CSSの@importなど
    • リソースみつかるまでに画像が流れるので遅くなる
    • Hidden resourceを使わない
    • preloadタグを使う
  • push
    • 優先順位漬け
    • リクエスト処理中にpush
    • CDNからpush
      • いくつか考えられている
        • RUM(ログとかから学習してpush)
        • DSLベースでやる
    • 複数の中間レスポンスと一つの最終レスポンスを返せる(HTTPの仕様)
      • Unicornはraw socket, Pumaはパッチ当てる必要あり
    • H2Oはmrubyでハンドラかける
    • Push vs Cache
    • 画像はpushしないようにしたほうがいい
      • pushしたデータとpullしたデータの優先順位がむずかしい
      • JSやCSSはpushしたほうがいい
      • head of line lock問題が顕在化しやすい
    • http2はポピュラーに
      • まだ使うモノによって差がある
      • H2Oつかってね

Optimizing Ruby

  • Urabe, Shyouhei
  • deoptimizotion over Ruby2.4
  • Rubyは遅い
    • どちらかというと遅い方
    • 最適化されてないから
      • 1 + 2 => 3?
        • +が再定義おこなわれる可能性があるため3とは限らない
  • Deoptimization
    • 再定義がなかったとして最適化
    • 再定義されていたらフォールバック
    • JRubyやRubinuisにもそれぞれで実装
  • Strategy
    • nativeにはしない
    • sequenceにパッチするかたち
  • 何がいいか
    • Pure C コード
    • program counterをいじらない
      • VMの状態を戻さなくてイイ
  • 再定義の検出
    • 別途カウンタを用意
  • Optimize on it
    • いくつかの最適化をした
    • これまでの最適化は動的におこなわれる
    • ほかにもやることはある
  • benchmarks
    • make benchmark
    • 一応はやくなってる
      • 最適化の結果シーケンスが同じになるものもある
    • vm2_eval
      • 邪悪なやつ
      • overheadで遅くなってるがまあこの程度ならはやくなってるかな
  • はやくなったのはめちゃはやくなった、遅くなったのはちょっと遅くなった
  • methodがpureかどうかの判定はrubyでわかる
    • ある、つくりました
  • 最適化の方法でメモリの使用量はふえてそうだけどどの程度増えてる?
    • 増えてますがまだ評価していない
  • 大きいアプリケーションでの評価は?
    • まだ
  • Folkで影響あるように思えるけどどうか?
    • そこのところ考えてなかったけどありうる
  • 最適化したあとのシーケンスが長くなる場合には?
    • まだそこは考えられてない、対応必要

Hijacking syscalls with (m)ruby

  • Franck Verrot
  • mrubyをいろんなシステムに組み込んできた
    • 今Redisやってる
  • System call
    • osとのinterface
  • Hijacking syscalls what for?
    • Sercuring Ruby apps is kinda tricky
  • なんでmrubyでsyscallsをオーバーライドするか
    • Rubyすきなので
    • Higher level
      • superでもとのが呼び出せる
    • creating an embeddable mruby
      • 組み込みやすい
      • モジュラー構造
      • 複数VMを単一プロセス
  • performance
    • naive implementationだと24倍遅い
    • optimized implementationだとnaiveより10倍速い
  • system callを置き換える理屈というかうれしさがイマイチぴんときてない

Dive into CRuby

  • NARUSE, Yui
  • CRubyへの貢献
  • 新機能
    • なぜ追加する => いまあるものじゃだめだから
    • 実際にどういうコードの場合にだめなのかということをしっかり固める必要がある
      • 必要は発明の母
    • 例:壊れた文字列
      • webクローラーでOK
      • 壊れたファイル NG
        • そもそも壊れたファイルを無理矢理読み込む必要はない
  • 新環境
    • しばしば動かないこともある
    • clang
      • gccと違う最適化する場合がある
    • Visual C++ 2015
      • C Runtimeがコンパチビリティーを破壊
      • かなり邪悪なコードをいれてうごくようになった
  • 最適化
    • ボトルネックを探す
      • derailed benchmarks
      • new rewlicでスタックトレースとれる
        • めっちゃ深いのでrails側で頑張ってください
      • no bottle neck => とりあえずString#blank?はやくする
    • Regexp#match?
      • $&への保存がない
      • SSE4.2で高速化 => 終わりが結構めんどくさい16byteないとSEGV
      • ARM SVE => 末尾でページをまたぐ場合の処理を考えている
    • Ruby VMの高速化
      • Cのレイヤー
      • perf report
      • vm_exec_core
        • core function of RubyVm
        • ここはbottleneckじゃない
    • こういうのを早くしてほしいなというベンチマークを用意できると、JITをいれるというモチベーションがあがるかも
  • Debugging/ Profiling/Tracing
    • 期待通りに動かない、遅い、クラッシュした
    • メモリを食ってる場合
      • perf-top
      • ps(1)
      • procfs
      • ObjectSpace
      • GC.State
      • sigdump
    • get stuck
    • SEGV
      • バグ報告するときには全部貼り付けておくってください
      • C levelのバックトレースが重要
        • 通常は非公開になっている関数名とかがとれる
      • core file
        • .gdbinit for CRuby
  • まとめ

おまけ

今日の弁当

今日も美味しかったです。はい。