问题标签 [scaling]

我正在开发一个由许多模块化 Web 应用程序组成的 Web 产品。对最终用户来说，它似乎是一个单一的应用程序，尽管各种组件被分解成它们自己的应用程序。

这样做的部分原因是它可以轻松地跨多个应用程序服务器进行水平扩展。

为了便于数据层的水平扩展，我们计划在数据库前面使用 Web 服务层。该层可以扩展到 N 台机器，并且它的每个实例都将单独处理缓存。

这个想法是应用程序将调用服务层负载均衡器，它将调用分配给服务实例，然后使用其缓存返回数据，或连接到数据库并查询数据。看起来这将是无需大量修改应用程序代码即可扩展的最简单的前瞻性解决方案。

但是出现了一些问题，我想在服务级别保留用户会话，以便每个应用程序只使用令牌进行身份验证，但是我不确定如何在所有服务机器上维护会话数据而没有单点故障。

关于如何解决这个问题的任何想法？关于建筑的任何其他想法？有没有其他人有过设计一个每天可以处理数百万次点击的网站的项目？

编辑：甚至没有想法？:(

我们已经在 Amazon EC2 中与HAProxy斗争了几天；到目前为止，体验非常好，但我们一直坚持从软件负载平衡器中挤出更多性能。我们并不完全是 Linux 网络专家（我们通常是一家 .NET 商店），但到目前为止，我们一直坚持自己的想法，尝试设置适当的 ulimit，检查内核消息和 tcpdump 是否存在任何违规行为。到目前为止，我们已经达到了大约 1,700 个请求/秒的稳定期，此时客户端超时比比皆是（我们一直在使用和调整httperf以此目的）。我和一位同事正在收听最新的 Stack Overflow 播客，其中 Reddit 的创始人注意到他们的整个网站都运行在一个 HAProxy 节点上，并且到目前为止还没有成为瓶颈。确认！要么不知何故看不到那么多并发请求，要么我们做错了什么，要么 EC2 的共享特性限制了 Ec2 实例的网络堆栈（我们使用的是大型实例类型）。考虑到 Joel 和 Reddit 的创始人都同意网络可能是限制因素这一事实，这可能是我们看到的限制吗？

任何想法都非常感谢！

编辑看起来实际问题实际上不是负载均衡器节点！在这种情况下，罪魁祸首实际上是运行 httperf 的节点。当 httperf 为每个请求构建和拆除一个套接字时，它会在内核中花费大量的 CPU 时间。当我们提高请求率时，TCP FIN TTL（默认为 60 秒）使套接字保持的时间过长，而 ip_local_port_range 的默认值对于这种使用场景来说太低了。基本上，在客户端（httperf）节点不断创建和销毁新套接字的几分钟后，未使用的端口数用完，随后的“请求”在此阶段出错，产生低请求/秒数和大量的错误。

我们也看过 nginx，但我们一直在使用 RighScale，他们有 HAProxy 的插入式脚本。哦，除非证明绝对必要，否则我们 [当然] 的最后期限太紧了，无法更换组件。幸运的是，在 AWS 上允许我们并行使用 nginx 测试另一个设置（如果有必要的话），并在稍后一夜之间进行切换。

本页很好地描述了每个 sysctl 变量（在这种情况下，调整了 ip_local_port_range 和 tcp_fin_timeout）。

我注意到有一些解决方案允许在 C#/ASP.NET 上使用 memcached：

• 内存缓存点网

• enyim.com Memcached 客户端

• 贝特

我应该使用哪一个？似乎 enyim 端口有更积极的发展，但我想看看你们推荐什么。

从 stackoveflow.com 的角度来看（由 2-3 名工程师组成的团队构建一个旨在扩展的网站项目），在开发过程的早期花费精力来构建基于 Lucene/Autonomy 的搜索是否有意义……而不是基于数据库全文搜索。

优点/缺点：
对于像 nutch 或自治这样的成熟 Lucene 实现，在后期迁移到 Lucene（这是不可避免的）的成本可以忽略不计。
大量添加额外的索引服务器（比如使用 nutch）来维护不断增长的搜索索引相对容易。
对于 Lucene 实现，我很可能需要一个额外的服务器来维护内存索引（在扩展过程的早期阶段）。

为了获得一些平滑的图形，我想通过因子 2 绘制过采样然后按比例缩小。

所以我正在做的是在wxMemoryDC中的wxBitmap上绘制过采样，然后在复制到我的 dc 之前将其缩小。下面的代码工作正常，但bitmapOversampled.ConvertToImage(); 非常慢。

有没有什么方法可以实现同样的效果，而不必从 wxBitmap 转换为 wxImage，反之亦然？

I really love the way Ajax makes a web app perform more like a desktop app, but I'm worried about the hits on a high volume site. I'm developing a database app right now that's intranet based, that no more then 2-4 people are going to be accessing at one time. I'm Ajaxing the hell out of it, but it got me to wondering, how much Ajax is too much?

At what point does the volume of hits, outweigh the benefits seen by using Ajax? It doesn't really seem like it would, versus a whole page refresh, since you are, in theory, only updating the parts that need updating.

I'm curious if any of you have used Ajax on high volume sites and in what capacity did you use it? Does it create scaling issues?

找到一个好的方法来做到这一点让我有一段时间感到困惑：假设我有一个包含一组点的选择框。通过拖动角，您可以缩放框中的点（之间的距离）。现在对于轴对齐的盒子，这很容易。取一个角作为锚点（从每个点中减去这个角，对其进行缩放，然后再次将其添加到该点）并将每个点 x 和 y 乘以框变大的因子。

但是现在取一个不与 x 和 y 轴对齐的框。当你拖动它的角时，你如何缩放这个框内的点？

I was trying to find online some exercises to practice scaling techniques (memchached, SQL Optimization, sharding dbs), but I could only find descriptions of these techniques, not any project on which to try them.

This link with slides on scaling techniques, is an interesting one, as it sums up some tools to achieve scalability quite well.

Is there a projecteuler kind of site for these kind of activities? Or at least some excercises (such as a downloadable ASP.NET/PHP site with obvious slowdowns, concurrency issues, subtle bugs) for people to try and learn how to fight this issue?

有没有人有过以多读单写方式扩展 SQL Server 的经验。如果没有，任何人都可以建议他们有经验的阅读密集型 Web 应用程序的合适替代方案

我知道问题标题不是最好的。让我解释。

我进行了大量的文本处理，将自然语言转换为 xml。这些文本文件上传速度相当快并被放入队列中。从那里它们被一个接一个地拉到后台工作程序中，该工作程序调用我们的解析器（使用 boost spirit）将文本转换为 xml 并将相关部分加载到我们的数据库中。

解析器一次可以做大约 100 个。我在后台工作人员上有限速器，现在只经常轮询我们的队列，因此它的执行速度不那么快。我现在不能抛出一个以上的后台工作人员，因为我的 http 请求开始下降——后台工作人员和网络服务器存在于同一台机器上，我相信这是因为 cpu 使用率达到 80-95%，尽管我们也可以使用更多的内存。

我需要更好地扩展它。你会怎么做呢？

在回答几个问题时：

• 我们使用亚马逊网络服务，因此购买廉价的额外硬件与生成一个新的亚马逊实例有点不同——也许有人做了一些代码来自动生成负载量的实例？

• 我们确实有一个 http 服务器，它只是将我们的文件塞入一个队列，所以它受到影响的唯一原因是因为 cpu 正忙于处理大量与解析相关的东西

• 我已经对我们的后台工作人员进行了速率限制，尽管我们没有在解析器本身中使用它

• 我还没有尝试过，但我过去使用过它——我需要为此写下一些基准

• 解析器与 Web 服务器完全分离——我们有 nginx/merb 作为我们的 Web/应用程序服务器和一个调用 c++ 的 rake 任务作为我们的后台工作者——但它们确实存在于同一台机器上