解决 .net Web 应用程序中的可伸缩性和性能问题

Posted 2023-02-23

【中文标题】解决 .net Web 应用程序中的可伸缩性和性能问题

【英文标题】：Addressing scalability ,performance in a .net web application

【发布时间】：2010-10-09 11:50:29

【问题描述】：

我正在开发一个拥有大量并发用户的 .net 门户。 因此可扩展性、性能需要在设计和架构中加以解决。 我们计划在应用程序中使用负载平衡。

记住这一点，在 IIS Web 服务器（托管 aspx、aspx.cs 文件）和应用程序服务器（托管 .net 程序集，如业务逻辑和数据访问层）之间进行通信的最佳方式是什么？ 应该是.net remoting 还是soap web service？还是有其他方法？

谢谢。

【参考方案1】：

来自Omar Al Zabir的这些文章中有一些不错的性能和可扩展性点。10 ASP.NET Performance and Scalability Secrets 和99.99% available ASP.NET and SQL Server SaaS Production Architecture （也可以看看他的书Building a Web 2.0 Portal with ASP.NET 3.5）

【参考方案2】：

学习异步编写。 例如，探索 CCR 运行时。

每个因等待 IO 响应而被阻塞的线程少一个可供您的系统使用。

关闭“理想化日志记录”，让您可以通过管理控制台重新打开它。但伐木往往是一个隐藏的瓶颈。

缓存缓存缓存！

如果第一次获取数据的成本很高，那么第二次就不要为它买单了！

避免 ASP.net 的会话状态 - 这可能会严重膨胀并导致页面响应速度大幅下降。

修改 http 标头以指定短浏览器缓存（5 秒 - 20 秒）（取决于内容的性质）

在您使用 GZIP 时使用它！

并使用大量内存

【参考方案3】：

这是我的建议

1) 将所有静态文件 - images、css、js 移动到 nginx 等负载均衡器。这将大大减少 IIS 服务器上的负载，并且它将有足够的空闲资源来服务于主要请求。

2) 考虑缓存并完全避免数据库访问。

3)尽量实现REST原则。

4) 将会话状态保持在最低限度 - 如果可能的话完全避免它。

【参考方案4】：

我建议您查看模式和实践组的性能指南，更具体地说是该指南的Chapter 6 - Improving ASP.NET Performance。我同意 Cheeso 的观点，如果可以的话，您应该认真考虑不要在物理上拆分您的应用程序层和 UI 层。 P&P 指南有以下注意事项：

避免不必要的进程跳跃

虽然进程跃点不像机器跃点那么昂贵，但您应该尽可能避免使用进程跃点。进程跃点会导致额外的开销，因为它们需要进程间通信 (IPC) 和封送处理。例如，如果您的解决方案使用企业服务，请尽可能使用库应用程序，除非您需要将企业服务应用程序放在远程中间层。

了解远程中间层的性能影响

如果可能，请避免进程间和计算机间通信的开销。除非您的业务需求要求使用远程中间层，否则请将您的演示、业务和数据访问逻辑保留在 Web 服务器上。将您的业务和数据访问程序集部署到应用程序的 Bin 目录。但是，出于以下任何原因，您可能需要远程中间层：

您希望在面向 Internet 的 Web 应用程序和其他内部企业应用程序之间共享您的业务逻辑。 您的横向扩展和容错要求决定了使用中间层集群或负载平衡服务器。 您的公司安全策略要求您不能将业务逻辑放在您的 Web 服务器上。

如果您无论如何都必须拆分应用程序逻辑，则可以使用 WCF 作为传输机制。我不确定它在性能方面如何与远程处理相提并论。但是，我似乎记得这是微软正在推动的指导方针。

Clemens Vasters（Microsoft .NET 服务总线的技术主管）在 MSDN 论坛上的 this answer 中谈论 WCF 与远程处理。

【参考方案5】：

还有其他方法吗？ 是的 - 不要分发您的对象。 最具可扩展性的方法是不要将您的对象彼此分开。问问自己，为什么要将一种风格的代码部署到“应用服务器”而另一种风格的代码部署到“Web 服务器”？这两个层之间进行的通信，如果它们是分布式的，将比本地调用昂贵得多（等等）。

对于当今的 64 位服务器、所有内存和热 CPU，以及 ASP.NET 卓越的内存管理，为什么不将您的业务逻辑和 DAL 与 ASPX 文件放在同一台物理机器上呢？为什么不？

如果您需要扩展，请添加更多服务器。简单的。

当然，分发是有充分理由的。最常见的充分理由与所有权领域有关 - 沿着几个轴：安全管理，甚至预算和控制。换句话说，对于后一种情况，如果团队负责运行业务逻辑，而一个单独的团队负责构建和运行 Web 层——那么分配这两个东西以允许管理的独立性可能是有意义的。分发计算机代码的大部分充分理由都源于使用或开发代码的人类组织的结构。

没有很好的技术理由为什么网页不应该在同一个 CPU 上运行，共享同一个 CLR VM 和内存堆，作为数据库访问层。

无论您如何处理分发，使用定义层之间连接的不太正式的接口来构建您的系统都是不明智的。如果您保留正式的接口，那么衡量分布式方法与共存方法的性能和效率应该没有问题。

【参考方案6】：

您真的需要应用服务器吗？你到底在说多大？例如 ***.com 每天有大约 50k 的唯一身份，并且没有应用服务器，所以我假设您说的比这大得多？大多数性能瓶颈都归结为数据库问题，因此我将专注于此。