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

发布时间：2020-12-16 07:33:28 所属栏目：asp.Net 来源：网络整理

导读：我正在开发一个.net门户网站,它将拥有大量的并发用户. 因此,可扩展性,性能需要在设计和架构中得到解决. 我们计划在应用程序中使用负载平衡. 记住这一点,在IIS Web服务器(托管aspx,aspx.cs文件)和应用程序服务器(托管.net程序集,如业务逻辑和数据访问层)之间

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

记住这一点,在IIS Web服务器(托管aspx,aspx.cs文件)和应用程序服务器(托管.net程序集,如业务逻辑和数据访问层)之间进行通信的最佳方式是什么？
它应该是.net远程处理还是肥皂网服务？还是有其他方法吗？

谢谢.

解决方法

还有另一种方法吗？是 – 不要分发您的对象.
最具扩展性的方法是不要将对象彼此分开.问问自己,为什么要将一种代码部署到“app server”,而另一种代码却转到“web服务器”？在这两个层之间进行的通信(如果它们是分布式的)将比本地呼叫更加昂贵(等等).

使用今天的64位服务器,具有所有内存,热CPU以及ASP.NET卓越的内存管理,为什么不将业务逻辑和DAL放在与ASPX文件相同的物理机器上？为什么不？

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

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

没有很好的技术原因,为什么网页不应该在同一个CPU上运行,共享相同的CLR VM和内存堆,就像数据库访问层一样.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!