コラム

CTC教育サービス・ホーム　＞　コラム　＞　Ruby on Rails 海外事情コラム　＞　第23回　フレームワーク選択時にパフォーマンスは重要か

Ruby on Rails 海外事情コラム

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第23回　フレームワーク選択時にパフォーマンスは重要か (野田貴子) 2017年10月

こんにちはー。野田貴子です。

今月も海外のRails情報で面白そうなものを意訳してご紹介しますね。興味がある方はご覧ください。

###

Web開発のためのフレームワークを選択する際に、フレームワークのパフォーマンスは問題になるのでしょうか。

その答えの一つとして、最近『Is Ruby Too Slow For Web-Scale?』というブログ記事が投稿されました。
https://www.speedshop.co/2017/07/11/is-ruby-too-slow-for-web-scale.html

以下はその要約です。

---

様々な言語やフレームワークのベンチマークランキングを見ると、Ruby on Railsよりも処理の速いフレームワークが多数存在していることがわかります。しかしベンチマークは統計と似たようなもので、間違った質問から正しい答えを得ることや、データが示していない結論を読者に誤認させることもできます。ですので、このベンチマークの結果を見て、「RailsアプリをSinatraで書き換えれば10倍速くなる！」と考えてしまうのは間違いなのです。
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=db&l=7p6ku3

また、もしそれでパフォーマンスが良くなるとしても、速さは重要でしょうか？どれだけのパフォーマンスが出れば十分な速さのWebアプリケーションであると言えるでしょうか。

パフォーマンスを考えるときに出てくる用語に、「スループット」と「レイテンシ」があります。「スループット」はサーバが一定時間あたりに捌けるリクエストの数、「レイテンシ」はサーバが1つのリクエストに対するレスポンスを返すのに必要な時間です。この2つは反比例します。

複雑なアプリケーションやRubyなどの動的言語の場合、「スループット」は低下し「レイテンシ」は上がります。重要なのは「レイテンシ」で、これはエンドユーザのエクスペリエンスに影響します。応答時間がかかればかかるほど、ユーザの待ち時間が増えるためです。

おもしろいのは、コンピュータのスピードは年々上がり続けるにもかかわらず、人間のスピードは変化しないということです。Jakob Nielsenは1993年にその調査を次のようにまとめています。

0.1秒：画面上のオブジェクトを直接操作しているとユーザが感じることができる上限。 1秒：コンピュータの反応を不当に待つことなく、コマンド空間を自由にナビゲートしているとユーザが感じられる上限。 10秒：ユーザがタスクに注意を払っていられる上限。
https://www.nngroup.com/articles/response-times-3-important-limits/

2017年現在、WebアプリケーションはただのフラットなHTMLファイルではありません。巨大なWebサイトはメガバイトサイズのJavaScriptやスタイルシートを含み、平均的なWebページはレンダリングに5秒もかかっています。「スループット」や「レイテンシ」などサーバーのパフォーマンスが多少改善されても、ブラウザ側の操作のユーザエクスペリエンスの前では大した違いはありません。

Rubyは高速な言語ではありませんし、Railsのような機能豊富なフレームワークはリクエストごとに多くの処理が動いています。ただ、もちろんRuby言語やRailsフレームワークも年々性能が上がっています。
http://engineering.appfolio.com/appfolio-engineering/2017/5/22/rails-speed-with-ruby-240-and-discourse-180

最近のRailsConfやRubyConfでは、新しい、より強力なマルチコアシステムへの興味が高まっています。パフォーマンスや並行性に関する話があまりにも多くありますが、言語はその2つの理由だけで終わるわけではありません。

この「○○言語は終わってる」という議論の中でベンチマークがよく取りざたされますが、どの言語やフレームワークにも、Webアプリケーションを書くのに適していないことを証明できるベンチマークはありません。パフォーマンスは言語が終わる際の問題ではないのです。

プログラマは自身の知識が増えずにキャリアが停滞することを恐れています。つまり、「○○言語は終わった」という議論の大部分は、その言語がWebアプリケーションの要件を満たせていないからではなく、プログラマたちの自己防衛意識によって引き起こされているのです。

ほとんどの組織では、ユーザが使う画面の方のスピードアップに重点を置いて、サーバーの方の性能改善コストを節約することができます。画面側が遅いと、ユーザエクスペリエンス、ひいてはWebサイトからの収益に影響を与えてしまうためです。Webアプリケーションのパフォーマンスにおいて、フレームワークの選択は現在では大した問題ではないのです。

結論：JavaScript、Go、Elixir、PythonはすべてダメダメなのでRubyを書きましょう！というのは冗談で、みなさんが一番生産的になれる言語やフレームワークを選びましょう。パフォーマンスではなく、Ruby on Railsのように人間工学に基づいているかどうかを重視してください。

---

一週間後、これに対する別のブログ記事『Rails Web-Scale is Expensive』が公開されました。合わせて読んでみてはいかがでしょうか。
https://hackernoon.com/rails-web-scale-is-expensive-b86facc11381

協力：株式会社Dive into Code　野呂浩良氏
https://diveintocode.jp/