Question

我们很有可能在接下来的几天内被科技碾压。不幸的是，我们还没有上线，所以我们没有很好地估计我们的系统如何处理生产受众。

我们的生产设置包含2个EngineYard切片，每个切片有3个mongrel实例，使用Postgres作为数据库服务器。

显然，我们的应用程序将如何支撑我们的实际代码和查询等等。但是，看看是否有任何关于期望或体验的负载的提示/指示会很好。通过它的人。 6个杂种实例（如果服务器可以接受它可能是8个）听起来像处理负载，或者至少是它的大部分？

Answer 1

我已经研究过多个由于病毒式增长而导致负载过高的rails应用程序。

您的杂种计数应基于几个因素。如果您的mongrels进行API调用或发送电子邮件并且必须等待响应，那么您应该尽可能多地运行。否则，尝试维持每个CPU核心一个杂种，可能还剩下几个。

确保您的服务器使用的是公平代理平衡器（不是循环法）。以下是执行此操作的nginx模块：http://github.com/gnosek/nginx-upstream-fair/tree/master

以下是一些关于改进和基准测试应用程序性能以处理负载的其他技巧：

<强> ActiveRecord的

Rails应用程序面临的最常见问题是ActiveRecord对象的使用率很低。当只需要一个查询时，可以很容易地进行100次查询。确定这可能是您的应用程序存在问题的最简单方法是设置New Relic。在向您网站上的每个主要页面发出请求后，请查看新的SQL概述。如果您按顺序看到大量非常相似的查询（从id = 1的帖子中选择*，从id = 2的帖子中选择*，从帖子中选择*），这可能表示您需要使用：包含在您的一个ActiveRecord呼叫中。

其他一些基本的ActiveRecord提示（这些只是我能想到的那些提示）：

如果您还没有这样做，请确保在数据库表上正确使用索引。
避免在视图中进行数据库调用，尤其是局部视图，可以很容易地忽略在视图中进行数据库查询的程度。将所有查询和计算推送到您的模型或控制器中。
避免在迭代器中进行查询。通常可以通过使用：include。
避免让rails尽可能为大型数据集构建ActiveRecord对象。当你像Post.find（：all）.size这样进行调用时，会为数据库中的每个Post实例化一个新类（它也可能是一个大型查询）。在这种情况下，您可能希望使用Post.count（：all），它将生成一个快速查询并返回一个整数而不实例化任何对象。
User..has_many :objects之类的关联会同时创建user.objects和user.object_ids方法。后者跳过ActiveRecord对象的实例化，可以更快。特别是在处理大量物体时，这是加快速度的好方法。
尽可能学习并使用named_scope。它可以帮助您保持代码的小巧，并使查询更加容易。

外部API＆amp;的ActionMailer

尽可能多，在处理请求时不要对外部服务进行API调用。您的服务器将停止执行代码，直到收到响应。这不仅会增加加载时间，而且你的杂种将无法处理新的请求。

如果您绝对必须在请求期间进行外部调用，则需要运行尽可能多的mongrels，因为您可能遇到许多混蛋等待API响应而没有执行任何其他操作的情况。（这是构建Facebook应用程序时非常常见的问题）

在某些情况下，同样适用于发送电子邮件。如果您希望许多用户在短时间内注册，请确保对ActionMailer传递消息所需的时间进行基准测试。如果它几乎不是即时的，那么您应该考虑在数据库中存储电子邮件，并使用单独的脚本来传送它们。

已经创建了像BackgroundRB这样的工具来解决这个问题。

<强>缓存

Here's a good guide on the different methods of caching in rails.

基准测试（定位性能问题） 如果您怀疑方法可能很慢，请尝试在控制台中对其进行基准测试。这是一个例子：

>> Benchmark.measure { User.find(4).pending_invitations } => #<Benchmark::Tms:0x77934b4 @cutime=0.0, @label="", @total=0.0, @stime=0.0, @real=0.00199985504150391, @utime=0.0, @cstime=0.0>

跟踪应用程序中缓慢的方法。那些是你想要避免经常执行的。在某些情况下，由于Rails具有查询缓存，因此只有第一次调用会很慢。您也可以使用Memoization自行缓存该方法。

NewRelic还将提供有关方法和SQL调用执行时间的概述。
祝你好运！

Answer 2

查看一些负载测试软件，如WEBLoad，或者如果您有钱，可以使用Quick Test Pro。这有助于您了解一下。在你的情况下，WEBLoad可能是最好的测试。

您可以生成数千个虚拟节点到达您的站点，您可以从该负载检查服务器的性能。

Answer 3

根据我的经验，看到我们的一些客户吸收了一些嘎吱嘎吱声，交通相当温和 - 而不是人们似乎期待的骨质破碎峰值。现在，如果你在雅虎的网页上进行联合制作，那么事情可能会有所不同。

如果您想了解他们如何处理它（Yahoo FP，请搜索Facestat.com的体验）。

如果您的服务器太热，我的建议就是准备关闭注册或访问您网站的更静态版本。使用监控/分析工具也是一个好主意，我喜欢FiveRuns管理工具，以便于设置。

Answer 4

由于您正在使用EngineYard，因此您应该能够分配更多计算机来处理负载

Answer 5

您的重大问题可能不是传入请求的数量，而是数据库中的数据量，显示您的查询未使用您期望的索引的位置，或返回过多数据，例如“用户列表”页面适用于10个用户，但是当您尝试在该页面上显示10,000个用户时死亡，因为您没有添加分页（will_paginate插件几乎是您的朋友 - 请注意“select count（*）”查询为你生成的）

所以要注意两件事：

缺少索引
每页数据太多

对于＃1，有一个插件在每次查询后运行'explain ...'查询，因此您可以手动检查索引使用情况

有一个插件可以为您生成各种类型的数据，可以帮助您填充数据库以测试这些查询。

对于＃2，使用will_paginate插件或其他方式来减少每页数据。

Answer 6

我们的设置与你基本相同，2个产品切片和EY的分段切片。我们发现ab是一个很好的负载测试工具 - 只需编写一个bash脚本，其中包含您希望被击中的URL并将其指向您的切片。观看NewRelic统计信息，它可以让您了解应用可以处理的负载以及您可能需要优化的位置。

我们还发现query_reviewer非常有用。它非常适合查找那些未编制索引的表和n + 1个查询。

如何准备成为技术人员

6 个答案: