解决 .net Web 应用程序中的可扩展性和性能问题
我正在开发一个 .net 门户，该门户将拥有大量并发用户.因此需要在设计和架构中解决可扩展性、性能问题.我们计划在应用中使用负载平衡.
I'm working on a .net portal which would be having lots of concurrent users. so scalability,performance need to be addressed in the design and architecture. We plan to use load balancing in the application.
记住这一点，IIS Web 服务器(托管 aspx、aspx.cs 文件)和应用程序服务器(托管 .net 程序集，如业务逻辑和数据访问层)之间的最佳通信方式是什么?应该是.net 远程处理还是soap web 服务?还是有其他方法?
Keeping this in mind,what would be the best way of communicating between IIS web server(hosting aspx,aspx.cs files) and application server (hosting .net assemblies like business logic and data access layer)? Should it be .net remoting or soap web service?or is there any other approach?
谢谢.
还有其他方法吗? 是的 - 不要分发您的对象.最具可扩展性的方法是不要将您的对象彼此分开.问问自己，为什么要将一种代码部署到应用服务器"，而将另一种代码部署到Web 服务器"?在这两层之间进行的通信，如果它们是分布式的，将比本地呼叫昂贵得多(等等).
Is there another approach? Yes - don't distribute your objects. The most scalable approach is to NOT to distribute your objects away from each other. Ask yourself, why do you want to deploy one flavor of code to an "app server" while another flavor of code goes to a "web server"? The communication that goes on between those two layers, if they are distributed, will be much much much much (etc etc) more expensive than a local call.
使用当今的 64 位服务器、所有内存和热 CPU，以及 ASP.NET 卓越的内存管理，为什么不将您的业务逻辑和 DAL 与 ASPX 文件放在同一台物理机器上呢?为什么不?
With today's 64-bit servers, with all of that memory, and the hot CPUs, and with ASP.NET's superior memory management, why not put your business logic and DAL on the same physical machine as the ASPX files? Why not?
如果您需要扩展，请添加更多服务器.简单的.
If you need to scale, add more servers. Simple.
当然，分发是有充分理由的.最常见的好理由与所有权领域有关 - 沿着几个轴:安全管理，甚至预算和控制.换句话说，对于后一种情况，如果团队负责运行业务逻辑，而一个单独的团队负责构建和运行 web 层，那么将这两件事分开以允许管理的独立性可能是有意义的.分发计算机代码的大部分理由都源于使用或开发代码的人类组织的结构.
There are good reasons, of course, to distribute. The most common good reasons have to do with domains of ownership - along several axes: security management, or even budget and control. In other words, to take the latter case, if team is responsible for running the business logic and a separate team is responsible for building and running the web layer -then it may make sense to distribute those two things to allow independence of management. Most of the good reasons for distributing computer code, have their origins in the structures of the human organizations using or developing the code.
一个网页不应该在同一个 CPU 上运行，共享同一个 CLR VM 和内存堆，作为数据库访问层，没有好的技术理由.
There is no good technical reason why a web page should not run on the same CPU, sharing the same CLR VM and memory heap, as the database access layer.
无论您对分发做什么，使用定义层之间连接的非正式接口来构建系统都是不明智的.如果您保留正式的接口，那么衡量分布式方法与协同定位方法的性能和效率应该没有问题.
Regardless what you do with distribution, it would be unwise to architect your system with less-than-formal interfaces defining the connections between the layers. If you keep formal interfaces, then it should be no problem for you to measure the perf and efficiency of a distributed approach versus a co-located approach.