何时使用负载平衡?

时间:2012-03-31 22:29:25

标签: asp.net windows load-balancing

我刚刚进入Web开发的更复杂部分。这可能不是最好的地方。但是,什么时候最好为Web项目获得负载平衡?我知道这取决于良好的设计/糟糕的设计,你可以访问一个网站有多少用户,而不会真正影响性能。但是,我打算编写一个可能有很多用户的新项目,我想知道我是否应该考虑负载均衡。意见欢迎;提前谢谢!

我不应该认为该项目最有可能是使用mongodb或pgsql后端的asp.net(webforms或mvc尚未决定)(再次仍在决定)。

4 个答案:

答案 0 :(得分:6)

负载平衡也可以是高可用性的一种形式。如果您的Web服务器出现故障怎么办?更换它可能需要很长时间。

通常,当您需要考虑吞吐量时,您已经很富有,因为您拥有大量用户。

Stackoverflow每月为10万个独立用户提供服务(6个左右)。如果您在8个小时内每秒不断产生10个HTTP响应,请考虑每天有多少请求:10 * 3600 * 8 =每天288000页的展示次数。您不会很快就会拥有那么多用户。

如果这样做,您可以将应用程序优化为每秒20个请求和CPU核心,这意味着您可以在商用服务器上获得每秒80个请求。那是很多

以后添加负载均衡器通常很容易。 LB可以使用cookie标记每个用户,以便将其固定到一个特定目标。你的应用程序不会注意到差异。一般

答案 1 :(得分:4)

这适用于电子商务网站吗?如果是这样,那么真正要问的问题是“网站停机的每一个小时,你输了多少钱?”如果这个数字很大,那么我会优先考虑负载平衡。

我见过的一个比较重要的架构决策影响了这个问题,就是使用会话变量。如果您的用户在访问期间在不同的服务器上结束,您需要能够提供无缝体验。会话变量不会从服务器传输到服务器,所以我会避免使用它们。

我在工作中支持这样的解决方案。我们在三台Windows 2k8服务器上运行四个(曾经是八个).NET电子商务网站(由两个主要/辅助SQL Server 2008数据库支持),每天约1300个(组合)订单。每个站点都是负载均衡的,并通过保持活动保持“在农场中”。关于这一点的好处是,我们可以将一台服务器关闭进行维护,而用户却没有注意到任何事情。当我们将其恢复时,我们会重新启用我们的复制服务,并且我们的更改会很快推送到其他两台服务器。

所以,是的,我建议给出一些像这样的解决方案。

答案 2 :(得分:2)

正如您所说,这取决于是否应该引入负载平衡。这取决于性能以及您要提供的用户数量。 LB还可以提高应用程序的可靠性 - 当一个系统崩溃时它不会停止。如果您可以看到您的项目变得非常庞大并为很多用户提供服务,那么我很乐意将您的应用程序设计为能够升级到LB,因此不要做任何非标准的事情。尽量避开自制的解决方案,并始终遵循良好的做法。如果以后您确实需要LB,则不需要更改您的应用程序。

<强>更新

您可能需要提前考虑,但不要以太多使应用程序复杂化为代价。不要偏执,准备一切快速闪电“以防万一”。例如,不要担心会话 - 会话管理可以随时轻松移动到SQL Server,这是LB的方法。如果你将来遇到一些瓶颈,但是你不需要立即实现缓存,那么缓存也会有所帮助 - 良好的设计(稳定的接口),分离和解耦将允许稍后添加缓存。所以再次 - 坚持良好的做法,不要关闭门,但也不要立即打开所有这些。

您可能会发现this文章很有趣。

答案 3 :(得分:2)

这里可能影响另一个参数并降低性能的参数是。

  • 带宽
  • 处理
  • 同步

您有多少用户以及您赢得的媒体一起使用。

因此,如果您必须提供大量视频/文件,那么您需要许多服务器来提供它。假设你没有,接下来认为需要检查的是什么,用户和处理。

根据我的经验处理速度慢的是锁定会话。因此,加快处理速度的一个重要步骤是进行全面的自定义会话处理,而您的页面将无法锁定另一个,并且您可以处理问题太多的用户。

现在进行下一步,假设您拥有一个保存所有数据的数据库,从负载平衡和许多计算机中获取,诀窍是为您显示的内容进行本地缓存。

因此,我们的想法是实际上避免过多的锁定使用户等待另一个,第二个想法是在每个不同的计算机上使用本地缓存从主数据库数据生成动态。

REF: Web app blocked while processing another web app on sharing same session

Replacing ASP.Net's session entirely

call aspx page to return an image randomly slow

始终在线

还有一个参数是,您可以创建一个解决方案,可以处理所有服务器的一个服务器的情况,以及所有的一个:)样式,您可以实际使用更多服务器作为备份原因。因此,如果一台服务器出于任何原因(例如更新和重新启动)关闭,其余服务器仍然可以工作和服务。