我正在开发一个拥有大量并发用户的.net门户网站。 因此，可扩展性，性能需要在设计和架构中得到解决。 我们计划在应用程序中使用负载平衡。
记住这一点，在IIS Web服务器（托管aspx，aspx.cs文件）和应用程序服务器（托管.net程序集，如业务逻辑和数据访问层）之间进行通信的最佳方式是什么？ 它应该是.net远程处理还是肥皂网服务？还是有其他办法吗？
感谢。
答案 0 :(得分：8)
还有其他方法吗？ 是 - 不要分发您的对象。 最具扩展性的方法是不要将对象彼此分开。问问自己，为什么要将一种代码部署到“app server”，而另一种代码却转到“web服务器”？在这两个层之间进行的通信（如果它们是分布式的）将比本地呼叫更加昂贵（等等）。
使用今天的64位服务器，包含所有内存，热CPU以及ASP.NET卓越的内存管理，为什么不将业务逻辑和DAL放在与ASPX文件相同的物理机器上？为什么不？
如果需要扩展，请添加更多服务器。简单。
当然，有充分的理由来分发。最常见的好理由与所有权领域有关 - 沿着几个方向：安全管理，甚至预算和控制。换句话说，如果采用后一种情况，如果团队负责运行业务逻辑，并且一个单独的团队负责构建和运行Web层 - 那么分配这两个东西以允许管理的独立性可能是有意义的。分发计算机代码的大多数理由都源于人类组织使用或开发代码的结构。
没有好的技术理由为什么网页不应该作为数据库访问层在同一个CPU上运行，共享相同的CLR VM和内存堆。
无论您如何处理分发，使用定义层之间连接的不正式接口来构建系统是不明智的。如果保留正式接口，那么测量分布式方法的性能和效率与共址方法相比应该没有问题。
答案 1 :(得分：4)
你真的需要一个应用服务器吗？你说的究竟有多大？例如，Stackoverflow.com每天有大约50万个独立用户，并且没有应用服务器，所以我假设你说的话比那个大得多？大多数性能瓶颈归结为数据库问题所以我会专注于此。
答案 2 :(得分：3)
我建议您查看模式和实践组的效果指南，更具体地说是指南的Chapter 6 - Improving ASP.NET Performance。我同意Cheeso的观点，如果可以的话，你应该认真考虑不要在物理上拆分你的应用层和UI层。 P＆amp; P指南有以下注释：
避免不必要的流程：
虽然进程跃点不像机器跃点那样昂贵，但应尽可能避免进程跃点。进程跃点会导致额外的开销，因为它们需要进程间通信（IPC）和编组。例如，如果您的解决方案使用Enterprise Services，请尽可能使用库应用程序，除非您需要将Enterprise Services应用程序放在远程中间层上。
了解远程中间层的性能影响
如果可能，请避免进程间和计算机间通信的开销。除非您的业务要求决定使用远程中间层，否则请在Web服务器上保留您的演示，业务和数据访问逻辑。将业务和数据访问程序集部署到应用程序的Bin目录中。但是，出于以下任何原因，您可能需要远程中间层：
- 您希望在面向Internet的Web应用程序与其他内部企业应用程序之间共享业务逻辑。
- 您的横向扩展和容错要求决定了中间层群集或负载平衡服务器的使用。
- 您的公司安全策略要求您不能将业务逻辑放在Web服务器上。
如果您必须完全拆分应用程序逻辑，则可以使用WCF作为传输机制。在性能方面，我不确定它是如何与远程处理相叠加的。但是，我似乎记得这是微软推动的指南。
Clemens Vasters（Microsoft .NET Service Bus的技术主管）在MSDN论坛的this answer中讨论了WCF与Remoting的对比。
答案 3 :(得分：1)
学会异步写作 例如，探索CCR运行时。
阻止等待IO响应的每个线程 少一个可用于您的系统。
关闭“理想化日志记录”，可以通过管理控制台重新启用它。但伐木往往是一个隐藏的瓶颈。
CACHE CACHE CACHE！
如果第一次获取数据费用昂贵，请不要为第二次付费！
避免ASP.net的会话状态 - 这可能会严重膨胀并导致页面响应速度大幅下降。
修改http标头以指定短浏览器缓存（5秒 - 20秒）（取决于内容的性质）
在你的时候使用GZIP！
并且使用大量内存
答案 4 :(得分：0)
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）
答案 5 :(得分：0)
以下是我的提示
1）将所有静态文件 - images，css，js移动到像nginx这样的负载均衡器。这将大大减少IIS服务器上的负载，并且它将有足够的免费资源来为主要请求提供服务。
2）考虑缓存并完全避免数据库访问。
3）尝试尽可能地实现REST原则。
4）将会话状态保持在最低限度 - 如果可能的话，完全避免它。