您使用的是AWSDBProxy吗？扩展时会有性能损失吗？

After a down vote, I humbly realized that my post was an enormous rant. So I've edited it and summed this down to just the question I'd really like to know. I apologize for my brash comments prior to this edit ;)

投票结束后,我谦卑地意识到我的帖子是一个巨大的咆哮。所以我编辑了它并将其归结为我真正想知道的问题。在编辑之前,我为自己的粗暴评论道歉;)

It seems that the only tutorials out there talking about using Amazon's SimpleDB in a rails site are using AWSDBProxy... Personally, I find this counter-intuitive to scaling out, considering the server layout of a typical Rails site below (using AWSDBProxy):

似乎只有在轨道站点中讨论使用亚马逊的SimpleDB的教程才使用AWSDBProxy ...就个人而言,我发现这与扩展相反,考虑到下面典型Rails站点的服务器布局(使用AWSDBProxy):

Plugin here: http://agilewebdevelopment.com/plugins/aws_sdb_proxy

插件在这里:http://agilewebdevelopment.com/plugins/aws_sdb_proxy

Image here: http://www.freeimagehosting.net/uploads/91be4e0617.png

图片来源:http://www.freeimagehosting.net/uploads/91be4e0617.png

As you can see, even if we add more mongrels, we have two problems.

如您所见,即使我们添加更多的杂种,我们也有两个问题。

We have a single point of failure far less stable than our load balancer

我们的单点故障远不如我们的负载平衡器稳定

We have to force all our information through this one WEBrick server

我们必须通过这个WEBrick服务器强制所有信息

The solution is, of course, to add more AWSDBProxies... but why not then just use the following code in say, a class, skipping the proxy all together?

当然,解决方案是添加更多AWSDBProxies ......但为什么不在一个类中使用以下代码,一起跳过代理?

service = AwsSdb::Service.new(Logger.new(nil),
                                CONFIG['aws_access_key_id'],
                                CONFIG['aws_secret_access_key'])
service.query(domain, query)

So what I'm getting at, is if you are using AWSDBProxy, what are you justifications for it? And if you are indeed using it, what is your performance like? If you have hard numbers, this would be even more appreciated!

所以我得到的是,如果您使用的是AWSDBProxy,您有什么理由呢?如果您确实在使用它,那么您的表现如何?如果你有硬数字,这将更加值得赞赏!

Thanks!

1 个解决方案

#1

I'm not using it, nor have I ever heard of it, but this is what I would think are reasonable reasons.

我没有使用它,也没有听说过它,但我认为这是合理的理由。

You're running your main app server on EC2, so the chance of Internet FAIL doesn't really affect you more than once.

您在EC2上运行主应用服务器,因此互联网失败的可能性并不会对您造成多次影响。

You run one proxy on each of your app servers. So it's connection going down is no worse than it's connection(s) to the database going down.

您在每个应用服务器上运行一个代理。所以它的连接下降并不比它与数据库连接的连接差。

Because it can be done. This is as good a reason as any in an open source project. Sometimes it takes building a thing before you know whether said thing is a good/bad idea.

因为它可以做到。这与开源项目中的任何原因一样。有时候在你知道所说的东西是好/坏的想法之前需要建立一个东西。

You don't have the traffic levels to need a load balancer. Then your diagram squashes down to a line, if not a single machine.

您没有流量级别需要负载均衡器。然后你的图表压扁到一条线,如果不是一台机器。

#1