0

Rails のスケーリングの問題についてよく耳にします。

Rails フレームワークで HTTP リクエストを処理するための実際のコストがどのくらいか知りたいです。つまり、入ってくるすべてのリクエストに対して何が起こらなければならないのでしょうか? クラス解析はありますか？構成？データベース接続の確立?

4

3 に答える 3

1

それは実際には、アプリケーションの設計自体は言うまでもなく、使用している Web サーバーと使用している構成に大きく依存します。関連する構成と設計の問題は次のとおりです。

  • fastcgi、古い学校の cgi、またはその他の要求処理メカニズムを使用しているかどうか (要求ごとにすべてのアプリ初期化コードを再実行する必要があるかどうかに影響します)
  • memcache (または代替キャッシュ戦略) を使用しているかどうか (データベース リクエストのコストに影響します)
  • 追加の負荷分散技術を使用しているかどうか
  • 使用しているセッション永続化戦略 (必要な場合)
  • 「開発」モードを使用しているかどうかに関係なく、コードファイルが変更されるたびにコードファイルが再ロードされます（私が思い出したように、おそらくリクエストごとです）。

ほとんどの Web アプリ フレームワークと同様に、接続プーリング、キャッシュ、およびプロセス管理のためのソリューションがあります。データベース アクセスを管理する方法はたくさんあります。通常のデフォルトのものは必ずしも最高のパフォーマンスではありませんが、その戦略を調整するのはロケット科学ではありません.

内部をより深く掘り下げた人は、おそらくもっと耐え難いほど詳細に話すことができますが、ほとんどのアプリは Apache 上の FastCGI か、よりレールに適した別の Web サーバーのいずれかを使用します。

于 2008-10-02T07:07:22.400 に答える
0

これは、 Railsリクエストのライフサイクルの概要です。これを実行した後、プロファイルを作成して最適化する特定のセクションを選択できます。

于 2009-03-03T22:51:07.720 に答える
0

Phusion Passenger (別名 mod_rails) のリリースまでは、デプロイの「標準」は FastCGI ではなく、Apache と mod_proxy (または Nginx など) がフロントにある Mongrel サーバーのクラスターを使用していました。

「Rails はスケーリングしない」の背後にある主な問題は、非常に複雑なスレッド化の問題がいくつかあるという事実です。これは、現在のバージョンの Ruby と利用可能なサービス提供メカニズムでは、Rails がスレッドセーフではなかったことを意味します。これは、高レベルの同時リクエストをサポートするために Rails アプリを実行するために複数のコンテナーが必要であることを意味します。Passenger は、これらすべてを内部で処理するため、この問題の一部を解決できません。また、メモリの処理方法を変更する Ruby (Ruby Enterprise Edition) のカスタム ビルドで実行することもできます。

これに加えて、Ruby と Rails の両方の今後のバージョンでは、スレッド化の問題に直接対処しており、この議論を完全に終わらせる必要があります。

私に関する限り、主張全体はかなり偽物です。「スケール」はアーキテクチャの問題です。

于 2008-10-03T04:35:45.483 に答える