Asp.net 解决.net web应用程序中的可扩展性和性能问题

我正在一个.net门户网站上工作，它将有很多并发用户。 因此，需要在设计和体系结构中解决可伸缩性、性能问题。 我们计划在应用程序中使用负载平衡

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

---

谢谢。

你真的需要应用服务器吗？你到底在说什么？例如，Stackoverflow.com每天有约5万个Unique，但没有应用服务器，所以我想你说的要比这个大得多？大多数性能瓶颈归结到数据库问题，所以我将集中讨论这个问题。

还有其他方法吗？是-不要分发对象。 最具伸缩性的方法是不要将对象彼此分散。问问自己，为什么要将一种风格的代码部署到“应用程序服务器”，而将另一种风格的代码部署到“web服务器”？这两层之间的通信，如果是分布式的，将比本地呼叫昂贵得多

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

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

当然，有很好的理由进行分发。最常见的好理由与所有权领域有关——沿着几个轴：安全管理，甚至预算和控制。换言之，对于后一种情况，如果团队负责运行业务逻辑，而另一个团队负责构建和运行web层，那么将这两件事进行分发以允许管理的独立性可能是有意义的。大多数分发计算机代码的好理由都源于使用或开发代码的人类组织的结构

没有很好的技术理由说明网页不应该在与数据库访问层相同的CPU上运行，共享相同的CLR VM和内存堆

---

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

我建议您看看模式和实践组的性能指南，更具体地说，是该指南。我同意CeSeo，如果你可以的话，你应该认真考虑不在物理上分割你的应用层和UI层。P&P指南有以下注释：

避免不必要的进程跃点

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

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

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

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

如果无论如何都必须将应用程序逻辑拆分，那么可以使用WCF作为传输机制。在性能方面，我不确定它与远程处理相比有什么不同。然而，我似乎记得这是微软正在推行的方针

---

Clemens Vasters（Microsoft.NET服务总线的技术负责人）在MSDN论坛上讨论了WCF与远程处理。

这些文章中有一些良好的性能和可扩展性。

和

（也可以看看他的书）

以下是我的建议

1） 将所有静态文件（图像、css、js）移动到nginx之类的负载均衡器中。这将大大减少IIS服务器上的负载，并且它将有足够的可用资源来处理主请求

2） 考虑缓存和避免数据库访问

3） 尽量执行REST原则

---

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

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

在等待IO响应时被阻止的每个线程都比系统可用的线程少一个

关闭“理想化日志记录”，保留通过管理控制台将其重新打开的功能。但日志记录往往是一个隐藏的瓶颈

快，快

如果第一次获取数据很昂贵，那么第二次就不用付钱了

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

修改http头以指定短消息