RubyはWebスケールには遅すぎる？
ネイト・ベルコペック (@nateberkopec) SpeedShop(詳細),Railsパフォーマンス・コンサルタンシー
要約：web開発のために、新しいwebフレームワークや、プログラム言語を選択しようとしていて、どれを選択すればよいか迷っていますか？パフォーマンスは考慮に入れたほうがよい。のでしょうか？
新しいwebアプリケーションのために、フレームワークやプログラミング言語をどのように選ぶのでしょうか？ (*1)
(*1)はいはい。わかっています。ベターリッジのヘッドラインの法則(訳注:「？」で終わるヘッドラインの答えは必ずNoというユーモア)です。もちろんRubyとRailsは大規模webサイトに使用するのに十分高速です。Shopifyが使用しており、世界で最も大規模なものの一つです。しかし、一部の人々は、Rails が「十分に速くない」と本当に考えているように見えます。これが本記事の内容です。
何か非常に小規模な開発をしている場合を除き、ほぼ確実にどれかを選択する必要があります。全ての web アプリケーションには、実行しなければならない項目が大量にあります：セキュリティ、オブジェクト関係マッピング、テンプレート化、テスト。さて、どれを選べばいいのか、どうしたらわかるのでしょうか？
これがレール(rails)だと思ってるでしょう？
まあ、あなたは決して遅いフレームワークを選びたくない。そうですよね？ 大掛かりで古く遅いRuby on Railsのようなフレームワークではなく、高速で現代的なライト・ウエイトのフレームワークがいい。違うでしょうか？しかし、そういった考え方はよくないでしょう。Ruby on Railsは過去10年間オール・イン・ワンのwebフレームワークの代表格として、速くて、小規模でも力のある、軽い、他のフレームワークからの攻撃に常にさらされてきました。Railsはもはや競争することができない恐竜なのでしょうか？
うーん、ベンチマークをいくつか見て、確かめることもできるかもしれません。確かに"高速"で"ライト・ウエイトな"フレームワークは、ベンチマークが良く、古くてだめなフレームワークでは悪いでしょう。
イエーイ！Railsひどいぜ
TechEmpowerなどでベンチマークの記事を見て、Ruby On Railsはまったく救いようがないと、考えることができるかもしれません。Sequelの作者のジェレミー・エバンス(Jeremy Evans)は、最近この比較から、他のRubyフレームワークでもRailsを葬ることができると指摘しました。あなたはこのベンチマークを見てこう考えるでしょう："すごい、SquelはActiveRecordとRailsより10倍高速だ！"
狭い意味ではあなたは正しいでしょう。ベンチマークは統計に似ています...間違った質問に正しい答えを与え、データで確認されていない結論を引き出すことがあります。ベンチマークを見て： "RailsアプリケーションをやめてSequelとSinatraで書き換えれば、今よりも10倍高速になる！"と考えたとしたら、間違っているでしょう。
そして、より速かったとしても、それは重要なのでしょうか？十分に速いwebアプリケーションというものが存在するのでしょうか？webアプリケーションのためのwebフレームワークや、プログラミング言語を選択する時でさえ、パフォーマンスは単純にどの程度重要なのでしょうか。
レイテンシとスループット
いくつかの定義から始めましょう。
サーバ・アプリケーションのデザインでは、レイテンシとスループットが非常に重要です。レイテンシは一つのリクエストにサーバーが応答するために費やした時間の総計です。スループットは同時にサーバが処理できるリクエスト数です。通常レスポンス/秒というような単位で計測されます。
サーバは漏斗のようなものです: レイテンシは、水の1分子が漏斗を通過するのにかかる時間、スループットは漏斗を通過する1秒ごとの水の量です。高レイテンシの高スループットのサーバは、長い広いチューブのようなものであり、低レイテンシの低スループットサーバは、短く、狭い口を持つ、広いディスクのように見えるでしょう。
ウェブ・アプリケーションのスループットは、一般的にはCPUと並列度で制約されます...webリクエストに応答するために、CPUサイクルがどの程度消費されるか、そしてホストマシンの全てのCPUコアに、どのように効率的に分散できるか？という問題です。CPU サイクルの量は、アプリケーションのドメイン、フレームワーク、言語によって制約されます...複雑なアプリケーションにはより時間がかかり、Rubyのような動的な言語は、CやRustのようなコンパイラ言語より多くのCPU命令を生成します。使用できる全てのCPUリソースの使用効率は、言語によって異なります...Goのgoroughtine、Elixirの"プロセス"、PythonやRubyのようなグローバルVMロックを駆使するマルチ・プロセス・サーバ、ノードのようなイベント駆動型アーキテクチャ、Javaのような本格的なスレッドの使用。
レイテンシは、しかしながら、さらにもっと重要です。レイテンシはスループットに逆比例するからです。Webアプリケーションのレイテンシを半分にすると、最大スループットは倍になります。レイテンシはまた、エンド・ユーザのエキスペリエンスにも影響します...500ミリ秒の応答時間は、webページの読み込みを待つために、ユーザーが追加で500ミリ秒を費やさなければならないことを明白に示しています。
ベンチマークの落とし穴
TechEmpowerのサーバ
TechEmpowerのwebフレームワーク・ベンチマークを見てみましょう。TechEmpowerはレイテンシと、最大スループットを6つの総合的なベンチマークから計測します。ベンチマークはとても高スペックなサーバで実行されます...10コア、20スレッドのCPUを4つ搭載しています(つまり、合計40コア、80ハイパー・スレッドになります)。ああ、そうだった、それから529GBのRAMも。
Railsでのベンチマークの実装
特に取り上げたいベンチマークの一つは、マルチ・クエリーのベンチマークです。とてもシンプルです...20クエリをSQLデータベースに対して連続して実行し、結果を返します。これはとても典型的なwebアプリケーションの負荷です...私がこれまで担当したRailsアプリケーションのほとんどは、大雑把に言ってこのように見えます。テンプレートをレンダリングするので、テンプレートに投入するためのデータを取得するために、SQLクエリをいくつか実行して返します。
14回目のベンチマークでは、典型的なRailsのセットアップ(puma-mri-rails)では、毎秒たった～531リクエストという計測結果でした。極めてライト・ウエイトなRubyのwebフレームワーク、Rodaは、Sequelと使用した時、使用したwebサーバによっては、7000リクエスト/秒という結果でした。
さて、これはRailsがRodaとSequelより10倍以上遅いという意味なのでしょうか？80コアのマシンで、531リクエスト/秒が、本当にRuby on Railsから引き出すことができる全てなのでしょうか？
TechEmpowerでのRailsのセットアップは、Rodaのセットアップと比較して、信じられないぐらい制限されていました。Pumaサーバーは8プロセスしか実行できないように設定されていました。一方Rodaは自動で自己最適化され、最終的には100プロセスを実行します。つまり、Railsのベンチマークは、使用可能なハイパー・スレッドのうち、せいぜい15%～20%しか使用しないのに、Rodaのベンチマークは全て使用します。ですので初めから、少なくとも5～8倍のスループットのペナルティーがRailsのベンチマークにあるということになります。しかし、解決は可能です。TechEmpowerはオープン・ソースで、プル・リクエストの部分をただ開いて修正することができます。これで15回目ではもっと良い結果が得られるでしょう。
TechEmpowerの別の測定値...平均リクエスト・レイテンシを見てみましょう。リクエスト・レイテンシに焦点を当てると、全ての言語とフレームワークをもっと同じ基準に置くことができます。グローバルVMロックや他の並列度に関する機能は、通常一つのリクエストを処理する場合は、あまり問題になりません(*2)。マルチ・クエリ・データベース・テストでPumaとRailsは129ミリ秒を記録しています。 Roda/Sequel/Pumaスタックは31.3ミリ秒です。
(*2)並行度に関する機能は、一般的にスループットを増加させますが、レイテンシは減少しません。
さて、すでに述べた通り、TechEmpowerのRailsのPuma設定は、Rodaの設定と比べて非常に制限されています。そのため、Railsはまだ大幅に時間を削減できる可能性がありますが、そのままにしておきましょう。簡単に、マイクロ・フレームワークやPhoenixのような他の競合プラットフォームでの、Webアプリケーションの平均的なレイテンシより、Railsは100ミリ秒遅いとしましょう。（実は、PhoenixはこのテストではRailsより遅いです。フレームワークの作者たちはこの結果に異議を唱えていますが、Railsのベンチマークも、同じことで遅くなっているのは間違いありません。)
コンピュータは進歩しますが、人間はそうではありません
コンピュータの面白いところは、コンピューターはより速くなっていくのに、不器用な人間は同じスピードに留まるということです。単に、コンピュータと人間の間のインタラクションが、どのくらい早くなければならないかという問題は、1960年代から研究されてきました。コンピュータが部屋のサイズより大きく、ミリ秒というよりは何時間も計算にかかっていた時代に戻れば、研究の目的がお分かりになるはずです。コンピュータがメインフレームと科学研究室から、一般生活の中に出ていくためには、もっと速くなければならなかったでしょう。しかしどのくらい速くなければならないのでしょうか？
ヤコブ・ニールセン(Jakob Nielsen)は1993年に結果をまとめました：
ヤコブ・ニールセン。この写真があるとはうれしいです。
0.1秒：ユーザがUIでオブジェクトを直接操作していると感じる上限。(...)
1秒：ユーザがコンピュータに過度に待たされず、自由にコマンドスペースをナビゲートしていると感じる上限。(...)
10秒：ユーザがタスクに集中しつづけられる上限。(...)
このトピックに関する記事全文をここで読むことができます。
Webが十分速いとは、一体どのくらいの速さなのでしょうか？
JavaスクリプトやCSSのない、HTMLレスポンスを返すだけの、本当に小さいwebアプリケーションがあると考えてみましょう。デフォルトのブラウザのスタイルを使用する、まったく単純なHTMLドキュメントです(*3)。ユーザが、webアプリケーションが置かれているwww.oursite.comにアクセスして、レスポンスを受け取るのに、どのくらいの時間がかかるのでしょうか？
(*3)この記事よりもさらにもっと退屈なスタイルのウェブサイトを少し想像してみてください。
そうですね...もしユーザがデスクトップ・コンピュータを使っていて、サーバが同じ国にあるなら、ユーザはコンピュータからパケットを受け取るのに20ミリ秒程度かかるでしょう。結果を返すために、再び20ミリ秒がかかります。これはベスト・ケース・シナリオです。世界の反対側からであれば、片道100ミリ秒ということもありえます。携帯電話で接続している場合は、300〜400ミリ秒もかかります。私の自宅のDSLでの接続は、USにあるほとんどのサーバに対して、50〜150ミリ秒の間で変化します。
最初のバイトが来るまで150ミリ秒だって？それはブレント・ランボー(Brent Rambo 訳注:1990年代初頭にAppleのデスクトップ製品の宣伝用ビデオに登場した子役)も納得。
さて、もし最初からすでに往復で～40ミリ秒のネットワーク・レイテンシがあるとしたら、1ミリ秒か、100ミリ秒でレスポンスをレンダリングするwebアプリケーションを、ユーザは区別することができるのでしょうか？つまり、あるアプリケーションは合計41ミリ秒かかり、他のものは141ミリ秒ということです。答えは絶対にNoです。どちらの場合でも、ユーザにはほとんど一瞬に見えます。ネットワークのコンディションが最悪な場合、違いは完全に消えてしまいます。したがって、わずかなレイテンシの違い(100ミリ秒かそれ未満、webフレームワークによる違い)は、スループット改善の効果においてのみ問題になります。
サーバはユーザ・エクスペリエンスのごく一部分にしか過ぎません
最・新のwebにようこそ
今は2017年です。webアプリケーションはもう単純なHTMLは返しません。ウェブ・サイトは巨大で、JavaScriptのバンドルはメガ・バイトのサイズに達しています。スタイル・シートはアポロ誘導コンピュータが10個あっても収まらないでしょう。それで、こういった環境で、1ミリ秒かそれ以下で応答するwebアプリケーションが、どのくらいの違いをもたらすというのでしょうか?
無視できるほどわずかです。今日では、平均的なwebページはレンダリングするのに5秒かかります。一部のJavaScriptのシングル・ページ・アプリケーションでは、最初にレンダリングする時、12秒以上かかることもあります。
サーバーの応答時間は、webページの読み込みとインタラクションに関する実際のユーザ・エクスペリエンスの、ほんのわずかな部分になるだけです...サーバーのレスポンス・タイムから99ミリ秒を削減するだけでは何も違いは起こりません。
限界があります: webアプリケーションは、ビデオ・ゲームではありません
ビデオ・ゲームの世界では、スピードは問題になります。言語が速いほど1フレームあたりより多くのポリゴンを、スクリーンに表示できると言えます。本当に上限はありません...ポリゴンが多く表示できるのは常に良いことです。つまり速い言語はシュミレーションの臨場感を高めるのに、常に役に立つでしょう。
このインターネット・ミームを知らない人へ
webアプリケーションはそうではありません。基本的に90%はシンプルなCRUDアプリケーションです。速い言語が機能や特徴の新しい可能性を開くことはありません。私たちが今までレンダリングしてきたのと同じHTMLのWebフォームを使い、数ミリ秒早くレンダリングするだけです。リクエストのレイテンシを減らす効果には限界があるのです。
Rubyは遅いので、Rubyのコードがもっとあると、さらに遅くなります
(マイク・ペルハム(Mike Pherham)どんなソフトウェアにも２つの究極のボトルネックがあります。メモリ・アロケーションとハッシュのルック・アップです。それ以外は全て最適化できます。)
マイク・ペルハム(Mike Pherham) 。最終的にRubyの内部構造の大半はハッシュテーブルにまとめられます。ですので...
Rubyは速い言語ではありません。 ですので、より少ないコードで実行すれば、より速いベンチマークの結果が得るでしょう。
Railsのような機能豊富なフレームワークには多くのコードがあり、リクエストごとに、より多くのコードを実行します。それらがより多くの処理をしているためです。
初心者コースのレベルのようですが、もう一度言わせてください。TechEmpowerや他のベンチマークは通常、機能に明らかな違いは生じません。TechEmpowerから得られることの全ては、この一見まったくわからないタグの羅列です。
そう。これが人類が読める理解しやすい機能比較なんだって。
TechEmpowerのように、違いがミリ秒で（あるいはマイクロ秒まで）測定される、スループットのマイクロ・ベンチマークで本当に測っているものは、特定のリクエストへ応答する時に、ある特定言語のランタイムが実行するCPU命令の数です。フレームワーク間の機能セットを比較する方法は 実質的にはTechEmpowerにはないので、全てのフレームワークは"対等な立場"に置かれます。それで、あなたはRailsは世界中で最も遅いwebフレームワークだと考えるのでしょう。事実としては、Railsはリクエストに応じて多くのことをしています。 新しいRailsアプリケーションを作成してミドルウェア・スタック（rake middleware）を見てください。Webアプリケーションに応じて、品質を良くするために行うべき、多くの作業がされています。他の多くのフレームワークは行っていません。少なくともデフォルトでは。
パフォーマンスはCPUや最大スループットよりも複雑です
TechEmpowerでは、CPUの使用がボトルネックになりますが、言語またはフレームワークのCPUパフォーマンスが、Webアプリケーションのパフォーマンスのボトルネックになることは、現実にはほぼありえません。 Webアプリケーションは特に複雑になるにつれ、かなりI / Oが重くなります。 最新のRailsアプリケーションは、3つかそれ以上のデータベースと、やり取りすることができます...SQLデータベース、バックエンド・ジョブ・プロセッサのRedis、キャッシュ用のMemcacheなど。データベースとのやり取りに費やされた時間が、レスポンスの25％か、それ以上を占めることはよくあります。
さらに、Ruby on Railsのパフォーマンス・コンサルタントとして、フレームワークや言語のCPUパフォーマンスとは関係のない、アプリケーションのデプロイに関する問題を多く見てきました：未熟なサーバの設定、メモリ・リークやメモリの肥大化、誤ったキャッシュの使い方。プログラマは、不思議なことに、自らアプリケーションのパフォーマンスを全て台無しにする方法を見つけようとしていたかのようです。
最後に、成熟した大半のWebアプリケーションでは、実行時間のせいぜい50％しかフレームワークに費されておらず、実際のアプリケーション・コードや、その他の追加の依存関係に、はるかに多く費されています。これをRubyで見るのはとても簡単です。スタック・トレースを見て、上位のフレームがどのくらいフレーム・ワークから来ているか見てください。多くないはずです。アプリケーションを同じ言語を使って、より速いフレームワークで書き直すことができたとしても、応答時間はせいぜい半分にしかならないということです。
月額1,000ドルの節約のために、アプリケーションを全部を書き換える
TechEmpowerのような、比較を行うベンチマークで示された情報を使って、人が何をするのかが心配です。家に帰って、"今週のお気に入り"のフレームワークもしくはスタックで、アプリケーションを書き換えるのでしょうか?それとも、新しい製品やサービスのためにスタックを選ぶ時、"遅い"スタックよりも"速い"スタックを選ぶのでしょうか?
やれやれ、PinterestはAds APIをElixirで書き換えたため、今や応答時間は1ミリ秒未満になりました。 確かに、以前より単純にいいですね。そうでしょうか？
理由が疑問です。なぜでしょう？ すでに確立されているので、エンド・ユーザのエクスペリエンスは変わりません。したがって、フレームワークを選び直す理由は2つだけです。a)より高速であるため、ホストするためのサーバーのコストが削減される。b)開発しやすいため、クオリティの高い機能をより早く提供するのに役立つ。
少しだけサーバのコストを見てみましょう。
大多数のWebアプリケーションは、毎秒1000リクエストよりはるかに少ない処理しかしていません。Webアプリケーション開発者の大多数は、全体で毎秒1000リクエストよりはるかに少ない処理をしているWebアプリケーションの会社に雇われていると言うことができるでしょう。ほとんどのwebアプリケーションは1000リクエスト/分以下しか処理していません。
平均応答時間250ミリ秒で20,000RPM（リクエスト/分、もしくは約300リクエスト/秒）に対応するRailsアプリケーションがあるとしましょう。 大規模で成熟したRailsアプリケーションでは、かなり平均的なプロフィールです。 このようなアプリケーションでは、適切に対応するには約200のPumaプロセスが必要になります。 これはHEROKUのPerformance-L dynoの約1ダース、つまり月額6,000ドルに相当します。
今、これをPhoenix, Node、もしくは何か好きな"今週のお気に入り"で書き換えて、125ミリ秒に減らすとしましょう。待ち時間を12ミリ秒とか、その他の驚異的に低い値には減らせないということを思い出してください：アプリケーションをサポートするデータベースへのI/Oで、未だに制限されているでしょう。
アプリケーションのレイテンシを半分にするということは、サーバが以前必要だった数の約半分になるということです。ですので、おめでとう：3000ドル/月を節約するために、アプリケーションを書き換えました（もしくはフレームワークを選びました)。アプリケーションをサポートするリレーショナル・データベースの負荷は変わらないので、コストは同じでしょう。アプリケーションが20,000 RPMを行うのに十分な大きさの時、アプリケーションのドメインに応じて、6人から50人のエンジニアがいることになります。1人のソフトウェアエンジニアには、給与と福利厚生で、最低でも月1万ドルの費用がかかります。では、エンジニア一人にかかる月々の費用の1/3を節約するという考えに方を元に、フレームワークを選択しているのでしょうか？そして、そのフレームワークで掴みどころのない人月というコストの1/3分まで、開発サイクルが遅くなったとしたら、コストは減るどころか増えてしまいます。サーバ・コストを元にフレームワークを選択するのは、明らかに馬鹿げたゲームです。
数ミリ秒で月に何万も節約できる巨大な企業のエンジニアリング・プラクティスを、なぜ盲目的に受け入れるのでしょうか？あなたはPinterest (もしくはNetflix, もしくは…)ではありません。あなたは違う問題を抱えていて、それでよいのです。
悪くなっていきません
コンピューターは遅くなっていきません。ヴィルトの法則(*4)は、確かに携帯電話アプリのような大半のエンド・ユーザ・アプリケーションに当てはまりますが、典型的なwebアプリケーションにはあまり当てはまりません。Ruby Webアプリケーション（と、他の全てのWebアプリケーション）はもっと速くなっていくでしょう。ハードウェアに磨きがかかっていくのが遅いために、1クロック・サイクルにCPU命令を詰め込む方法を見つけたり、そのクロック・サイクルでさえ速くしたり、より多くのコアをプロセッサー・ダイに詰め込むといったことが続いていくからです。
(*4) ソフトウェアはハードウェアが高速化するより急速に低速化する
そして、言語も遅くなりません。 Appfolioのノア・ギブス(Noah Gibbs)は、Rubyの各マイナー・バージョンごとに、平均応答時間が約5-10％減少することを示しました。
幸せについて話しましょう
パフォーマンスの終焉論者は間違ってきました。これからもずっと間違い続けるでしょう。2007年にこの紳士の言ったことを引用します。
どの実装が次のRubyプラットフォームのデファクトになるかにかかわらず、一つ明らかなことがあります：人は、より新しく、より強力なマルチ・コア・システムの活用に興味を持っています(RailsConfとRubyConfsでErlangへの関心が、最近急激に高まっていることが示すように)。Rubyが大量のデータ処理を扱うソリューションの重要な部分になるにつれて、需要は増加するだけです。
そして10年後、 PumaやUnicornのようにpreforkされたwebサーバを通じた、マルチ・コアへのスケーリングは、いまだに十分すぎるほど良好です。Rubyはまだ死んでいません。私は提案されているGuildモデルによってもたらされる可能性に興奮しています。しかしこの言語は、それまで使用できませんか？ いいえ。
Webフレームワークやプログラミング言語に関する議論の方向を、私は変えたいと思っています。実際には効果は限定的で、コストは最小限に抑えられ低くなっている状況なのに、パフォーマンスと、並列性についての議論が多すぎます。言語は並列性やパフォーマンスの機能だけを理由にして、なくなることはありません。
より良い議論として意義がありインパクトがあるものは、私にとって、どのフレーム・ワークが、より高い品質のソフトウェアを、より幸せに速く書くのに役立つかということです。私は、その問いの答えを知っています。おそらくあなたにとっての答えと違うでしょう。
“ポリグロットたち”と“最新の熱いスタック”
(訳注:ポリグロットとは複数言語を使いこなせる人のこと)
エンジニアの一部には“最新の熱いスタック”ではないソフトウェアを書くのが、全然うれしくない人がいます。エンジニアは常に解決すべき新しい問題、学ぶべき何か新しいことを探しています...そして、それは素晴らしいことです！ 私にはまったく関係ないことではありますが。ニューヨークRubyカンファレンスのGORUCOは、"ポリグロット・カンファレンス"なるものを今年始めました。講演者は Python, Elixir, Rust, Reactと静的型付けの特色について講演を予定しています。これを発表した会議の主催者、マイク・デレッシオ(Mike Dalessio)のブログ記事は墓石のようです。
ベンチマークは、"Xは死んだ”という議論で、よく揺れます。上で示したように、どんな言語やフレームワークも、webアプリケーションを書くのに適していないと、ベンチマークで証明することはできません。パフォーマンスは心配することではありません。
逆に、Webアプリケーションに関するパフォーマンスの議論は、ほとんどがFUD(訳注:偽情報戦術)です。スタック全体をただ書き直すのに、費やされたエンジニアリングの時間や、ハッカー・ニュースで見た、いかす新しいおもちゃで遊べるようになるために、マネジメントへ説明していることを正当化しようとして、広められたものです。
プログラマはいつもキャリアが時代遅れになるのを恐れています。知的に停滞することを恐れる人もいます...トラックの部品会社の注文システムを稼働させ続けるために、RPGを書いている、バック・オフィスの不愛想な老人になってしまうのではないかと。そして、ほぼ全員が失業を恐れています。給料や仕事を置き去りにして、彼らのスタックから世界が離れていってしまうのではないかと心配しているのです。こういった恐れは事実です...しかし、「スタックXは死んだのか！」という議論の大半は、webアプリケーションの要件に対する懸念ではなく、恐怖よって活発になっていることを理解しましょう。
楽しさとゲーム
明確にさせてください...パフォーマンスはそれでも重要です。 ほとんどの組織では、エンド・ポイントの高速化に集中することでサーバー・コストを節約でき、またそうするべきです。特に遅いエンドポイントは、カスタマー・エクスペリエンスや収益に影響を及ぼすかもしれないので、スピード・アップするべきです。Webアプリケーションのパフォーマンスに、フレームワークの選択は、どれだけほんののわずかな意味しかないか、上で説明してきました。
また、私はTechEmpowerをけなしているわけではありません。 これは大規模なプロジェクトで、ドメインの専門家たちに支えられています。PRを行い、結果に関するどんな問題も修正しています。私の意見では本当に優秀な人たちで、特定のスタックのために議論を進めようとしたり、ベンチマークに参加しようとしたりはしていません。
結論として、JavaScript、Go、Elixir、およびPythonはすべてダメです。Rubyを書いてください:) いいえ、もちろん違います...あなたにとって、生産性が高いものを書いてください。あなたがWebプログラマーなら、パフォーマンスではなく、人間工学に基づいてツールを選択できるようになって、それをラッキー・スターとして数えてください。
https://twitter.com/garybernhardt/status/879945502556422144
(ゲイリー・ベルンハート(Gary Bernhardt)コンピューティングの最高のルール：コンピュータは、クリエータの世話をするために存在するべきであり、決してその逆ではない。)
ウェブ・サイトを高速化したいですか？
私はネイト・ベルコペック （@nateberkopec）です。 フル・スタック・エンジニアの観点から、ウェブのパフォーマンス、主にフロント・エンドとRubyのバック・エンドについて、オンライン記事を書いています。 もし、この記事が気に入って、次の記事について知りたい場合は、連絡をください。 毎週1通程度、Eメールを私から直接送ります。スパムではありません。控えめです。
Railsパフォーマンス完全ガイド
私が書いた「Railsパフォーマンス完全ガイド」を見てください! Ruby on Railsアプリケーションをより速く、よりスケーラブルに、より簡単にメンテナンスするためのツールを提供する、フル・スタックコースです。 361ページのPDF、プライベートSlack、15時間以上のビデオ・コンテンツが含まれています。
