「RailsConf 2017のパフォーマンス関連の話題」は今回で完結です。
- 第1回: BootsnapやPumaなど -- 開発中のRailsをBootsnapで倍速起動するなど
- 第2回: rack-freezeやsnip_snipなど -- スレッドバグや未使用カラムの検出など
- 第3回: 「あなたのアプリサーバーの設定は間違っている」など（本記事）
概要
原著者より許諾を得て翻訳・公開いたします。
- 元記事: Railsconf 2017: The Performance Update
- 著者: Nate Berkopec (@nateberkopec): Railsのパフォーマンスコンサルタントです。
- 主著: The Complete Guide to Rails Performance
楽しい画像はすべて元記事からの引用です。
RailsConf 2017のパフォーマンス関連の話題（3）「あなたのアプリサーバーの設定は間違っている」など（翻訳）
7. あなたのアプリサーバーの設定は間違っている
私は今回のカンファレンスで「あなたのアプリサーバーの設定は間違っている」（スポンサー: Heroku）というタイトルで講演いたしました。現時点ではまだ動画はアップされていませんが、私のTwitterアカウントをフォローいただければアップされたときにお知らせいたします。
私がこれまでコンサルティングしてきたアプリで見つかった問題の第1位は「アプリサーバーの設定ミス」（Puma、Unicorn、Passengerなど）でした。企業のアプリサーバーに設定ミスがあると月額コストが数千ドルにも達し、アプリのパフォーマンスも30%から40%ほど低下することがあります。これはひどい事態です。ぜひ私の講演をご視聴ください。
8. パフォーマンスパネル
カンファレンスのラス日に、Richard、Eileen、そして私でパネルディスカッションが行われました。司会はSam Saffronです。そのときの動画がこちらです。
出席者のSavannahが、マインドマップっぽいクールなものを作ってくれました。
the penultimate talk: a panel on performance with @nateberkopec @rafaelfranca @samsaffron @schneems @eileencodes #railsconf pic.twitter.com/srRe4ebPSW
— savannah🏳️🌈 (@Savannahdworth) 2017年4月27日
9. パフォーマンス関連のその他の話題
RailsConfでは、この他にもRubyのパフォーマンスに関心のある方なら押さえておきたいプレゼンが他にもいくつかありました。
訳注: いずれも35分程度の動画です。
プレゼンはShopifyのSimon Eskildsenです。Simonの話し方はいつも部外者にわかりやすくてとても素晴らしいですね。世界トップ100入りするサイトをRailsで構築したい方は必見です。
GitHubのBryana Knightによるこのプレゼンでは、SQLクエリを最大限に高速化する方法について解説しています。プレゼンの大半はインデックスとインデックスの利用状況の調査方法にあてられています。
Braulio Carrenoによる、もうひとつのパフォーマンス戦記です。
10. 秘密のプロジェクト
ここには詳しく書きませんが、ある人物から実にクールなJavaScriptプロジェクトを見せていただきました。そのプロジェクトは「シングルページアプリ（SPA）を持たない人のためのJavaScriptフレームワーク」とでも言うべきもので、Turbolinksアプリや、JavaScriptコードを大量に導入しながら他のフレームワークを使っていないアプリで非常に高い効果がありそうに見えました。外見上は「控えめな（unobtrusive）JavaScript」フレームワークと似た感じです。これについては、プロジェクトがpublic releaseにこぎつけたときにお知らせいたします。
いいかぼうず、$(document).readyを追加し始めたら一巻の終わりだ、そこから先は...
私の個人的な意見ですが、Turbolinksの問題のひとつは「Turbolinksを使える複雑なアプリをビルドする学習用リソースや教育用理論が少なすぎる」ことだと思っています。TurbolinksではアプリのJavaScriptに対してさまざまなアプローチを必要とします。たとえばBackbone.jsやAngular.jsなどのSPAフレームワークを使いたい、以前キッチンシンクからturbolinks:load hooksにダンプしたときと同じようにJavaScriptを書きたいだけなのに、そこから悪夢が始まります。このフレームワークは、ページの振る舞いに一種のゴールデンパス（golden path）を追加することでこうした問題を解決できそうに思えました。
11. HTTP/2
HTTP/2についてはAaronのキーノートスピーチでも少し触れられていましたが、会場の廊下でAaronやEvanと立ち話したときにRackでのHTTP/2サポートへの道筋について議論になりました。
私はアプリの前にHTTP/2対応のCDNを配置して済ませるという従来の方法を擁護してきましたが、Aaronと私はこの点でかなり意見が合いました。Aaronは、RackのenvハッシュにHTTP/2固有のキーを追加することで、リクエストがHTTP/2対応であるかどうかがRackから知らされたときにHTTP/2の機能をアプリで自由に使えるコールバックを作りたいと考えています。しかし私は、Server PushがCDNやリバースプロキシでおおよそ実装できることから、その用法はかなり限定されるのではと考えています。
12. RPRG/Chatについての続報
RubyConf 2016の続報で、私は次のように書きました。
最後に、「パフォーマンス野郎たちの集い」ではいくつか素晴らしい議論が繰り広げられ、2つの大きな成果がありました。Ruby Performance Research Group（RPRG）と「Ruby Performance」コミュニティグループです。
私はこれらのプロジェクトに今でも参加し続けています。近々Research Groupに何かアップされると思います（私は高マルチスレッドのRubyアプリにおけるメモり断片化についてのネタがあります）。コミュニティグループの方にもその後でときどきアップされるでしょう。
13. カラオケ！
こちらがJon McCartieでございます、皆さま
RailsConf 2017についてはだいたい以上です。来年のさらなるRubyパフォーマンスの話題とカラオケを楽しみにしています。
（終わり）
関連記事
- RailsConf 2017のパフォーマンス関連の話題（1）BootsnapやPumaなど（翻訳）
- Railsで検索を高速化するならこれで決まり！Sunspotで始めるSolr入門
- [Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた