海边有规模吗？
Seaside被称为“异端网络框架”。使它成为异端的原因之一是它有很多共享状态。然而，根据我目前的理解，这阻碍了轻松扩展。
另一方面，Ruby on Rails 共享尽可能少的状态。众所周知，它的扩展性非常好，即使它与现代的 Smalltalk 虚拟机相比速度很慢。 flickr 使用 php 并已扩展到极其庞大的基础设施......
那么有人在 Seaside 的扩展方面有一些经验吗？
Seaside is known as "the heretical web framework". One of the points that make it heretical is that it has much shared state. That however is something which, in my current understanding, hinders easy scaling.
Ruby on rails on the other hand shares as less state as possible. It has been known to scale pretty well, even if it is dog slow compared to modern smalltalk vms. flickr uses php and has scaled to an extremly big infrastructure...
So has anybody some experience in the scaling of Seaside?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
拉蒙·莱昂 (Ramon Leon) 在他的（优秀）博客上分享了他在升级海滨方面的一些经验。您可以通过有关配置和调整 Seaside 的示例代码阅读非常具体的想法。
享受吧:-)
http://onsmalltalk.com/scaling-seaside -更高级的负载平衡和发布
http://onsmalltalk.com/scaling-seaside-redux-enter-the-penguin
http://onsmalltalk.com/stateless-sitemap-in-seaside
Ramon Leon shares some of his experience on upscaling seaside on his (excellent) blog. You can read very concrete ideas with sample code about configuring and tuning seaside.
Enjoy :-)
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
简短回答：
你可以像地狱一样扩展Seaside应用程序，是的
长答案：
在 IT 领域，扩展是一回事，但它有两个维度：
几乎每个人都考虑过垂直维度的扩展。直到英特尔和朋友们遇到了一些物理障碍并开始添加内核以弥补目前无法添加 MHz 的情况。
从那时起，我们开始更加意识到水平扩展是一种可行的方法。
我为什么要告诉你这个？
因为Seaside是一个运行在虚拟机中的smalltalk镜像，与单核处理器的服务器中的系统情况大致相同。
以此为基础，您可以通过创建服务器集群来扩展 Web 应用程序。这是自然的事情，这是容错的事情，是拓扑智能的事情，是灵活的事情，我想你明白了......
所以，如果为了扩展，你会做同样的事情英特尔&朋友们，你们拥抱水平之路。而且它比垂直方式更便宜（这将引导您使用既好又贵的 IBM 和 Sun 服务器）。
RoR 应用程序通常是水平扩展的。谷歌有无数廉价的服务器来完成他们的任务。无论人们多么戏剧化地想给你留下深刻印象，向你扔一堆容易被遗忘的推特鲸鱼，它都可以完美地工作。
如果他们和你谈论这个，你只要有礼貌，听听他们说的话，但记住这一点：
顺便说一句，亚马逊也做了类似的事情（它是一种地理定位，因此它们可以提高使用最接近您位置的集群来满足您的请求的机会）。
另一方面，Avi 扩展 dabbledb（Twitter 收购的基于 Seaside 的 Web 应用程序公司）的方式是每个客户帐户使用一个虚拟机（按需启动和关闭这些虚拟机）。
图像中有很多状态并不会使缩放变得不可能或复杂。
只是不同而已。
解决方法是使用使用粘性会话的负载均衡器，这样您就可以用一个图像来处理用户会话的所有请求。您可以让负载均衡器后面的任何工作映像都可以参与给定应用程序的任何用户。差不多就是这样了。
为了能够做到这一点，您需要在工作人员之间共享持久对象。所有用户数据库都需要可供工作人员随时访问，并且需要很好地处理并发性。
我们以这种方式设计了可扩展的气流。
它在经济上也很方便，因为您可以从非常小的 N 开始（取决于您的第一台服务器的 RAM），然后根据需要增加它，直到达到硬件限制。
一旦达到硬件限制，您只需将另一台主机添加到集群并重新配置平衡器（以及对数据库的访问）。
简单、经济、优雅。
Short answer:
you can scale Seaside applications like hell yah
Long answer:
In the IT domain, scaling is one thing but it has two dimensions:
Almost everybody thought about scaling in the vertical dimension. That was until intel and friends reached some physical barriers and started to add cores to compensate the current impossibility of adding MHz.
That's when all we started to be more aware of scaling horizontally as the way to go.
Why am I telling you this?
Because Seaside is a smalltalk image running in a VM and that is roughly the same situation of a system in a server of a monocore processor.
Taking that as foundation, you scale web apps by making a cluster of servers. It's the natural thing to do, it's the fault tolerant thing to do, is the topologically intelligent thing to do, is the flexible thing to do, I guess you get the idea...
So, if for scaling, you do the same as intel & friends, you embrace the horizontal way. And it's even cheaper that the vertical way (that will lead you to IBM and Sun servers that are as good as expensive).
RoR applications are typically scaled horizontally. Google has countless cheap servers to do their thing. It works perfectly fine no matter how dramatized people want's to impress you throwing at you a bunch of forgettable twitter whales.
If they talk to you about that, you just be polite and hear what they say but remember this:
BTW, Amazon does something like that too (and it kind of couple geolocation so they enhance the chances of attending your requests with the cluster that is closest to your location).
On the other hand, the way Avi scaled dabbledb (Seaside based web application company bought by twitter) was using one vm per customer account (starting up and shutting down those on demand).
Having a lot of state in an image doesn't make scaling impossible nor complicated.
Just different.
The way to go is with a load balancer that uses sticky sessions so you can have one image attenting all the requests of an user session. You make things so any worker-image behind the load balancer can attend any user of a given app. And that's pretty much it.
To be able to do that you need to share the persistent objects among workers. All the users databases needs to be accessible by the workers at anytime and need to deal well with concurrency.
We designed airflowing scalable in that way.
It's economically convenient too because you can start with N very small (depending on the RAM of your first server) and increase it on demand until you reach the hardware limit.
Once you reach the hardware limit, you just add another host to the cluster and recofigure the balancer (and the access to the databases).
Simple, economic and elegant.
http://dabbledb.com/ 似乎可以很好地扩展。此外，还可以使用 GemStone GLASS 来运行 Seaside。
http://dabbledb.com/ seems to scale quite well. Moreover, one can use GemStone GLASS to run Seaside.
在本次采访中，Avi Bryant 是 Seaside 的创建者和 DabbleDB 联合创始人
解释他们如何扩大规模。
据我了解：
每个客户都有自己的吱吱声
图片。
当客户到来时，Apache 根据用户名决定将其发送到哪个端口。
当
根据端口启动客户的 Squeak 映像。
这样它就可以增长到无限数量的服务器。
我认为这个解决方案适合他们，基于他们的应用程序的具体情况，每个客户不需要在他们之间共享信息。所以不需要集中式数据库。
无论如何，与其看我半成品的总结，不如看采访。
On this interview Avi Bryant the creator of Seaside and Co founder DabbleDB
Explains how they make it scale.
From what I understand:
each customer has it's own Squeak
Image.
When a customer comes Apache decides based on the user name which port to send it to.
Based on the port it starts the customer's Squeak Image.
That way it can grow to an infinite number of servers.
I think this solution works for them based on the specifics of their application each customer doesn't need to share info between them. So no need for o centralized DB.
Anyway it is better to watch the interview rather than my half-made summary.
是的，海边的规模缩小得惊人。单个开发人员可以很好地为小组创建和维护复杂的应用程序。
【时隔几年再回到这个话题】
这实际上比扩大规模更重要。计算机速度仍然大幅增长，99% 的应用程序现在可以在一台机器上运行。开发速度，尤其是维护速度现在完全主导着 TCO。
Yes, Seaside scales down fantastically. A single developer can create and maintain complex applications for small groups very well.
[coming back to this after a few years]
This actually is much more important than scaling up. Computer speed still grows a lot, and 99% of all applications can now run on one machine. Speed of development, and especially maintenance now totally dominates TCO.
我会将您的问题稍微改写为：Seaside 是否会阻止/阻止您创建可扩展的应用程序？我通常会说不。 Seaside 没有默认的方式来存储数据（就像 php 一样，它没有，尽管 Seaside 为您提供了一些额外的选项），而且我的印象是，在扩展方面，与数据交互往往是最大的障碍。
如果您想将数据存储在整体 SQL 数据库中（例如使用 Rails），您可以这样做。或者您可以使用对象数据库。或者，您可以为每个用户使用单独的对象数据库，或者为每个项目使用单独的数据库，或者为每个用户和项目使用单独的数据库。或者，您可以将所有内容存储在一系列平面文件中，或者将数据作为对象存储在虚拟机内存中。
由于连续性，您不需要在每次网页调用时从数据存储中重新获取数据。当您使用桌面应用程序时，您可以在用户开始与其交互时从数据存储中提取数据，设置适当的变量，然后在网络调用之间使用这些变量，直到用户完成数据处理，此时您可以更新数据存储区。当您不共享状态时，您必须在每个网络调用中访问数据存储。
当然，这并不意味着扩展是免费的，它只是意味着您有更大的领域来搜索扩展解决方案。
话虽如此，对于许多应用程序来说，rails 的扩展性会更容易，因为有大型的 Rails 托管解决方案（以及 php），它们将为您提供大量资源，而无需租用和设置自定义盒子。
这些只是我阅读和与人交谈的印象。
I would rephrase your question slightly to: does Seaside prevent/discourage you from creating applications that scale? I would say usually no. Seaside doesn't have a default way to store your data (just like php on its doesn't, though Seaside gives you a few extra options) and my impression is interacting with your data tends to be the biggest hurdle when it comes to scaling.
If you want to store your data in a monolithic SQL db, like with rails, you can do that. Or you can use an object database. Or you can use a separate object database for each user, or separate db for each project, or a separate db for each user and project. Or you can store everything in a series of flat files or you can just store your data as objects in your VM's memory.
And because of continuations you don't need re-fetch your data out of your datastore on every webpage call. As when you are using a desktop application you can pull data out of your datastore when your user begins interacting with it, set the appropriate variables, and then use those variables between webcalls until the user is done with the data at which point you can update the datastore. When you don't share state you have to hit the datastore on every single webcall.
Of course this doens't mean scaling is free, it just means you have a larger domain in which to search for scaling solutions.
All that said, for many applications rails will scale much easier simply because there exist large hosting solutions for rails (and php for that matter) that will offer you a huge amount of resources without having to rent and setup a custom box.
These are just my impressions from reading and talking to people.
我刚刚提醒一下，Pharo 的成功案例有一个链接：阿根廷的一个大型健康保险的 Seaside Web 应用程序，具有多达 1000 个并发用户。
Pharo 成功案例
Issys 跟踪：
服务器
I just reminded that there is link on Pharo's success stories : a Seaside Web application with up to 1000 concurrent users for a large health insurance in Argentina .
Pharo success stories
Issys Tracking:
affinity)
从维基百科的文章来看，它完全是一头猪。在此之前，它还没有发展到我听说过的程度。 :)
From the Wikipedia article, it's a total pig. Prior to that, it hadn't scaled to the point where I'd heard of it. :)