RailsConf 2017のパフォーマンス関連の話題(3)「あなたのアプリサーバーの設定は間違っている」など(翻訳)

「RailsConf 2017のパフォーマンス関連の話題」は今回で完結です。

概要

原著者より許諾を得て翻訳・公開いたします。

楽しい画像はすべて元記事からの引用です。

RailsConf 2017のパフォーマンス関連の話題(3)「あなたのアプリサーバーの設定は間違っている」など(翻訳)

7. あなたのアプリサーバーの設定は間違っている

私は今回のカンファレンスで「あなたのアプリサーバーの設定は間違っている」(スポンサー: Heroku)というタイトルで講演いたしました。現時点ではまだ動画はアップされていませんが、私のTwitterアカウントをフォローいただければアップされたときにお知らせいたします。

私がこれまでコンサルティングしてきたアプリで見つかった問題の第1位は「アプリサーバーの設定ミス」(Puma、Unicorn、Passengerなど)でした。企業のアプリサーバーに設定ミスがあると月額コストが数千ドルにも達し、アプリのパフォーマンスも30%から40%ほど低下することがあります。これはひどい事態です。ぜひ私の講演をご視聴ください。

8. パフォーマンスパネル

カンファレンスのラス日に、Richard、Eileen、そして私でパネルディスカッションが行われました。司会はSam Saffronです。そのときの動画がこちらです。

出席者のSavannahが、マインドマップっぽいクールなものを作ってくれました。

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パフォーマンスの話題とカラオケを楽しみにしています。

(終わり)

関連記事

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833

コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。
これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。
かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。
実は最近Go言語が好き。
仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

BPSアドベントカレンダー

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ