シーサイドは「異端のウェブフレームワーク」として知られています。それを異端にするポイントの1つは、それが多くの共有状態を持っているということです。しかし、それは私の現在の理解では、簡単なスケーリングを妨げるものです。
一方、Ruby on Railsは、可能な限り少ない状態を共有します。現代のsmalltalkvmsに比べて犬が遅い場合でも、かなりうまくスケーリングすることが知られています。flickrはphpを使用しており、非常に大きなインフラストラクチャに拡張されています...
では、Seasideのスケーリングの経験はありますか？
Ramon Leon は、彼の (優れた) ブログで、海辺のアップスケーリングに関する彼の経験の一部を共有しています。seaside の構成と調整に関するサンプル コードを使用して、非常に具体的なアイデアを読むことができます。
楽しみ ：-）
http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing http://onsmalltalk.com/scaling-seaside-redux-enter-the-penguin http://onsmalltalk.com/ステートレス サイトマップ イン シーサイド
簡単な答え: シーサイド アプリケーションをスケールできます。
長い答え: IT ドメインでは、スケーリングは 1 つのことですが、2 つの側面があります。
ほとんどの人は、垂直方向のスケーリングについて考えました。それは、Intel と友人がいくつかの物理的な障壁に到達し、MHz を追加することが現在不可能であることを補うためにコアを追加し始めるまででした。
それが、進むべき道として水平方向のスケーリングをより意識し始めたときです.
なぜ私はあなたにこれを言っているのですか？
Seaside は VM で実行される smalltalk イメージであり、モノコア プロセッサのサーバー内のシステムとほぼ同じ状況だからです。
それを基盤として、サーバーのクラスターを作成することで Web アプリをスケーリングします。それは自然なことであり、フォールトトレラントなことであり、トポロジ的にインテリジェントなことであり、柔軟なことでもあります。
したがって、スケーリングについては、Intel & Friends と同じように、水平方向を採用します。そして、垂直方向よりもさらに安価です (これにより、高価な IBM および Sun サーバーにたどり着きます)。
RoR アプリケーションは通常、水平方向にスケーリングされます。Google には、目的を達成するための無数の安価なサーバーがあります。どんなに脚色された人々があなたに忘れられがちなさえずりのクジラを投げつけてあなたに感銘を与えたいと思っても、それは完全にうまく機能します.
彼らがそれについてあなたに話したら、あなたは礼儀正しく、彼らの言うことを聞くだけですが、次のことを覚えておいてください：
ところで、Amazon もそのようなことを行っています (これは一種の地理位置情報を組み合わせているため、現在地に最も近いクラスターでリクエストに対応できる可能性が高くなります)。
一方、Avi が dabbledb (Twitter によって買収された Seaside ベースの Web アプリケーション会社) をスケーリングする方法は、顧客アカウントごとに 1 つの VM を使用していました (必要に応じてそれらを起動およびシャットダウンしました)。
画像に多くの状態があるからといって、スケーリングが不可能になったり複雑になったりすることはありません。
ただ違う。
その方法は、スティッキー セッションを使用するロード バランサーを使用することです。これにより、1 つのイメージがユーザー セッションのすべての要求に対応できるようになります。ロード バランサーの背後にあるすべてのワーカー イメージが、特定のアプリのすべてのユーザーに対応できるようにします。そして、それはほとんどそれです。
これを可能にするには、永続オブジェクトをワーカー間で共有する必要があります。すべてのユーザー データベースは、ワーカーがいつでもアクセスできる必要があり、並行性を適切に処理する必要があります。
そのようにスケーラブルなエアフローを設計しました。
非常に小さい N から始めて (最初のサーバーの RAM に応じて)、必要に応じてハードウェアの制限に達するまで増やすことができるため、経済的にも便利です。
ハードウェアの制限に達したら、別のホストをクラスターに追加し、バランサー (およびデータベースへのアクセス) を再構成するだけです。
シンプル、経済的、そしてエレガント。
http://dabbledb.com/は非常にうまくスケーリングしているようです。さらに、GemStone GLASSを使用して Seaside を実行できます。
このインタビューでは、Seaside and Co の創設者である DabbleDB の作成者である Avi Bryant が、どのようにスケールを実現したかを説明しています。
私が理解していることから：
各顧客には独自の Squeak Image があります。
顧客が来ると、Apache はユーザー名に基づいてどのポートに送信するかを決定します。
ポートに基づいて、顧客の Squeak イメージを開始します。
そうすれば、無限の数のサーバーに成長できます。
このソリューションは、各顧客が情報を共有する必要がないアプリケーションの詳細に基づいて機能すると思います。したがって、集中型 DB は必要ありません。
とにかく中途半端なまとめよりインタビューを見たほうがいいです。
はい、シーサイドは素晴らしく縮小します。1人の開発者が、小グループ向けの複雑なアプリケーションを非常にうまく作成および保守できます。
[数年後にこれに戻る]これは実際にはスケールアップよりもはるかに重要です。コンピュータの速度は依然として大幅に向上しており、すべてのアプリケーションの99％を1台のマシンで実行できるようになりました。開発のスピード、特にメンテナンスは現在、TCOを完全に支配しています。
あなたの質問を少し言い換えます: Seaside は、スケールするアプリケーションを作成することを妨げたり、思いとどまらせたりしますか? 私は通常ノーと言うでしょう。Seaside にはデータを保存するためのデフォルトの方法がありません (PHP と同じように、Seaside はいくつかの追加オプションを提供しますが、そうではありません)。私の印象では、スケーリングに関しては、データの操作が最大のハードルになる傾向があります。 .
レールのようにモノリシックな SQL データベースにデータを保存したい場合は、それを行うことができます。または、オブジェクト データベースを使用できます。または、ユーザーごとに個別のオブジェクト データベース、プロジェクトごとに個別のデータベース、またはユーザーとプロジェクトごとに個別のデータベースを使用できます。または、すべてを一連のフラット ファイルに保存するか、データをオブジェクトとして VM のメモリに保存するだけです。
また、継続のため、Web ページの呼び出しごとにデータストアからデータを再取得する必要はありません。デスクトップ アプリケーションを使用している場合と同様に、ユーザーが操作を開始したときにデータストアからデータを取得し、適切な変数を設定してから、ユーザーがデータを使い終わるまでこれらの変数を Web コール間で使用して、その時点で更新することができます。データストア。状態を共有しない場合、Web コールごとにデータストアにアクセスする必要があります。
もちろん、これはスケーリングが無料であることを意味するのではなく、スケーリング ソリューションを検索するためのより大きなドメインがあることを意味するだけです。
とは言っても、多くのアプリケーションでは、カスタム ボックスをレンタルしてセットアップしなくても膨大な量のリソースを提供する、Rails (および php) 用の大規模なホスティング ソリューションが存在するため、Rail ははるかに簡単に拡張できます。
これらは、本を読んだり、人と話したりして感じたことです。
Pharoのサクセスストーリーにリンクがあることを思い出しました。アルゼンチンの大規模な健康保険に最大1000人の同時ユーザーがいるSeasideWebアプリケーションです。
Issysトラッキング：
ウィキペディアの記事から、それは完全な豚です。それ以前は、私が聞いたほどの規模にはなっていませんでした。:)