您使用 AWSDBProxy 吗? 横向扩展时是否会影响性能?

发布于 2024-07-13 13:12:37 字数 944 浏览 11 评论 0原文

似乎唯一讨论在 Rails 站点中使用 Amazon SimpleDB 的教程是使用 AWSDBProxy...就我个人而言,考虑到下面典型 Rails 站点的服务器布局(使用 AWSDBProxy),我发现这与扩展是违反直觉的:

插件位于:http://agilewebdevelopment.com/plugins/aws_sdb_proxy

图片位于:http://www.freeimagehosting.net/uploads/91be4e0617.png

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

  1. 我们的单点故障远不如我们的负载均衡器稳定
  2. 我们必须通过这台WEBrick服务器强制我们的所有信息

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

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

所以我的意思是,如果您正在使用 AWSDBProxy,那么您使用它的理由是什么? 如果你确实在使用它,你的表现如何? 如果您有确切的数字,那就更感激了!

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):

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

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

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

  1. We have a single point of failure far less stable than our load balancer
  2. We have to force all our information through this one WEBrick server

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?

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!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

や三分注定 2024-07-20 13:12:37

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

  1. 您在 EC2 上运行主应用程序服务器,因此互联网故障的可能性不会对您造成多次影响。
  2. 您在每台应用程序服务器上运行一个代理。 因此,连接中断并不比数据库连接中断更糟糕。
  3. 因为这是可以做到的。 这是一个与开源项目中的任何理由一样好的理由。 有时,需要先构建一个东西,然后才能知道该东西是好还是坏。
  4. 您没有达到需要负载均衡器的流量级别。 然后你的图表即使不是一台机器,也会被压缩成一条线。

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

  1. You're running your main app server on EC2, so the chance of Internet FAIL doesn't really affect you more than once.
  2. 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.
  3. 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.
  4. 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.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文