在.NET Web应用程序解决可扩展性，性能 [英] Addressing scalability ,performance in a .net web application

问题描述

我工作的这将是具有大量并发用户的.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?

感谢。

推荐答案

是否有另一种方法的是 - 不要散布你的对象。
最具扩展性的方法是不要将远离彼此分发对象。问问你自己，你为什么要code的一种口味部署到应用服务器，而code的另一种味道变为网络服务器？该推移这两个层之间的通信，如果它们分布，将是非常非常得多（等等等等）不是本地呼叫更昂贵。

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层 - 那么它可能是有意义的分发这两件事情，让管理的独立性。大多数的好理由分发计算机code，使用或开发code有他们在人类组织的结构起源。

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.

不管你分配做什么，这将是不明智的建筑师您的系统低于正式接口定义各层之间的连接。如果你保持正式的接口，那么它应该是没有问题的，你衡量一个分布式的方法对同一位置的方法的PERF和效率。

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.

这篇关于在.NET Web应用程序解决可扩展性，性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！