シーサイドは「異端ウェブフレームワーク」として知られています。それを異端にする点の1つは、多くの共有状態を持つことです。しかし、私の現在の理解では、容易にスケーリングを妨げるものです。シーサイドスケールですか？
一方、Ruby on Railsは可能な限り少ない状態で共有します。それは、たとえそれが現代の小規模なVMに比べて遅い犬であっても、かなりよくスケールすることが知られている。 flickrはPHPを使用し、極端に大きなインフラストラクチャに拡張されています。
だから誰もシーサイドのスケーリングの経験はありますか？
短い答えITドメインで 、スケーリングは一つのことですが、それは、二次元があります
ほぼすべての人が垂直次元でスケーリングを考えました。それはIntelと友人がいくつかの物理的障壁に達し、現在のMHzを追加することが不可能であることを補うためにコアを追加することになりました。
これは、私たちがすべての方法を水平方向に拡大することに気付き始めたときです。
なぜ私はあなたにこれを伝えていますか？
シーサイドはVMで実行されるスモールトークイメージであり、モノコアプロセッサのサーバーのシステムとほぼ同じ状況です。
これを基礎として、サーバーのクラスタを作成してWebアプリケーションを拡張します。それは自然なことです。フォールトトレラントなことです。トポロジー的にインテリジェントなやり方です。柔軟なやり方です。
スケールすると、インテルと同じことをしてください&お友達、あなたは水平方向を受け入れます。そして、それは垂直的な方法（それは高価なほど良いIBMとSunのサーバーにあなたを導く）がさらに安いです。
RoRアプリケーションは通常、水平方向に縮尺されています。 Googleには、無駄な無駄なサーバーがありません。どのように劇的な人々があなたに忘れられないツイッタークジラの束を投げて印象づけても、それは完璧にうまく動作します。
彼らはそのことについてあなたに話をする場合は、あなただけの礼儀正しく、彼らが言うことを聞くが、これを覚えて：
を行って（そしてそれは一種のカップルジオロケーション、彼らはあなたの場所に最も近いクラスタであなたの要求に出席の可能性を高めるために）。一方、Avi scaled dabbledb（twitterで購入したSeasideベースのWebアプリケーション会社）は、顧客アカウントごとに1つのVMMを使用していました（オンデマンドでの起動とシャットダウン）。
イメージに状態が多いとスケーリングが不可能で複雑になりません。
まったく異なります。
スティッキセッションを使用するロードバランサを使用すると、ユーザーセッションのすべての要求に1つのイメージを付けることができます。ロードバランサの背後にある作業者イメージは、任意のアプリケーションの任意のユーザーに参加できるようにします。そしてそれはかなりです。
これを行うには、永続オブジェクトをワーカー間で共有する必要があります。すべてのユーザーデータベースは、いつでも作業者がアクセスできる必要があり、並行性を十分に考慮する必要があります。
このようにスケーラブルな風通しを設計しました。
非常に小さいN（最初のサーバーのRAMによって異なる）から始めることができ、ハードウェアの制限に達するまでオンデマンドで増加できるので、経済的にも便利です。
ハードウェアの制限に達すると、クラスタに別のホストを追加し、バランサ（およびデータベースへのアクセス）を再構成するだけです。
シンプルで経済的でエレガントです。
Ramon Leonは、彼の（優秀な）ブログで海辺を高めた経験があります。海辺の設定とチューニングに関するサンプルコードを使って、非常に具体的なアイデアを読むことができます。
http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-publishing http://onsmalltalk.com/scaling-seaside-redux-enter-the-penguin http://onsmalltalk.com/stateless-sitemap-in-seaside
http://dabbledb.com/ :-)お楽しみは非常によくスケールするようです。さらに、GemStone GLASSを使ってシーサイドを実行することもできます。
まあ... dabbledbは何とか特別なものです。これは、顧客ごとに別々のVMを実行するためです。私はそれが「スケール」の通常の意味だとは思わない。そしてGLASSにとっては、LAMPのようなスケールになっています.Googleのようなものではありません。 – nes1983
私はあなたの質問に若干の言い換えをします：Seasideはスケールするアプリケーションを作成できないようにしますか？私は普通はいいえと言います。シーサイドにはデータを保存するデフォルトの方法がありません（シーサイドではいくつかのオプションがありますが、PHPのように）。スケーラビリティーに関しては、データとのやりとりが最大のハードルになる傾向があります。
レールと同じように、モノリシックSQLデータベースにデータを保存する場合は、それを行うことができます。または、オブジェクトデータベースを使用することもできます。または、ユーザーごとに別々のオブジェクトデータベースを使用することも、プロジェクトごとに別々のデータベースを使用することも、ユーザーとプロジェクトごとに別々のデータベースを使用することもできます。または、すべてをフラットファイルのシリーズに格納することも、VMのメモリにオブジェクトとして保存することもできます。
継続性のため、すべてのWebページ呼び出しでデータストアからデータを再フェッチする必要はありません。デスクトップアプリケーションを使用しているときと同様に、ユーザーがデータストアとのやりとりを開始するときにデータストアからデータを引き出し、適切な変数を設定してから、ユーザーがデータを更新するまでWebCallでこれらの変数を使用できますデータストア。状態を共有していないときは、すべてのWebcallでデータストアにヒットする必要があります。
もちろん、これはスケーリングを意味するものではありません。スケーリングの解決策を探す大きなドメインがあることを意味します。
多くのアプリケーションでは、カスタムボックスをレンタルして設定することなく膨大な量のリソースを提供する大規模なホスティングソリューション（およびその点ではPHP）が存在するため、 。
これは、読んで話す人の印象です。
継続とセッションの料金は、リクエストごとに状態を復元する必要がないことによって支払うことができますか？面白い。 –
それはそれを置くための良い方法です、そして、それは返済される場所に注目する価値があると思います。中央データストアの負荷を持ち上げ、負荷をアプリケーションサーバーに転送します。これらは、アプリケーションサーバーを追加することができますので、スケーリングについて考えているときに作成したい転送の種類です。 ウェブページの呼び出しごとに継続時間がdbに達した場合でも、そのヒットを中心的な障害の原因から外すと、それでもスケーリングが勝ちます。 –
オンthis interviewアビブライアントシーサイドと共同設立者のDabbleDBの作成者 彼らの規模をどのようにして説明しますか。私が理解から
：
各顧客は、それ自身のSqueakの イメージを持っています。
お客様がApacheに来ると、送信するポートのユーザー名に基づいて決定されます。
ポートに基づいて、顧客のSqueak Imageが開始されます。
こうすることで、無限の数のサーバーに拡張できます。
このソリューションは、各顧客がそれらの間で情報を共有する必要のないアプリケーションの仕様に基づいて動作すると考えています。したがって、集中DBを必要としません。
とにかく私の半完成の要約ではなく、インタビューを見る方がいいです。
はい、シーサイドは劇的にスケールダウンします。 1人の開発者は、小規模なグループのために複雑なアプリケーションを作成して管理することができます。
[これが数年後に戻ってくる] これはスケールアップよりもはるかに重要です。コンピュータの速度はまだまだ高まり、すべてのアプリケーションの99％が1台のマシンで実行できるようになりました。開発のスピード、特にメンテナンスがTCOを完全に支配しています。あなたは
長い答えYAH地獄のようなシーサイド・アプリケーションを拡張することができ ：
Pharoの成功事例には、アルゼンチンの大規模な健康保険のための1000人までの同時ユーザーを持つSeaside Webアプリケーションがあります。
ISSYSトラッキング：
は、私はかなりうまくスケールすることが知られているレールあなたのコメントによる驚いています。 Twitterは主にこの時点で動作しますが、私は彼らが標準的な軌道からかなり離れているとの印象を受けます。私は、フレームワークを拡大するための本質的な叙事詩ではないと思う傾向があります。 –
Twitterは本質的にメッセージ放送である何かのためのデータベースをバックエンドとして使用します。 スケーリング - 私が理解しているように、より多くのハードウェアを使用してより多くの需要を満たすことがいかに簡単かを意味します。 Railsの原作者の一人であるDHHが»[...]では、何も変更せずにほとんどすべてのWebサーバーとAppサーバーを追加できるので、Railsがこの定義にうまく対応できることを提案します。 ] [1]それは私の理解に合っています。 [1]：http://www.loudthinking.com/arc/000479.html –
私が理解しているように、TwitterはRailsではなくScalaを使用しています。 – Mei