支持Web应用程序中约400多个并发用户的设计注意事项

use*_*358 7 c# asp.net iis performance

我正处于中型asp.net c#项目的开端,并且具有应用程序性能要求,能够支持大约400多个并发用户.

在构建满足此类性能和可用性标准的应用程序时,我需要记住哪些事项?该页面需要在5秒内完成.我计划将应用程序和数据库放在不同的物理机器上.从编码和应用程​​序分层的角度来看: -

  • 如果我通过WCF服务将数据库层暴露给应用程序层,是否会妨碍性能?我应该使用直接tcp连接吗?
  • 如果我使用Entity框架或其他ORM或企业库数据块,这是否重要?
  • 我应该记录数据库或文本文件的异常吗?
  • 如果正在构建的代码最终将满足这些性能标准,我如何检查开发?或者这是否是我在开发阶段需要担心的一点?
  • 我是否需要将我的数据库连接代码和其他类保存在应用程序生命周期中很少更改的查找数据,这些类在静态类中是否可以通过应用程序的生命周期使用?
  • 我应该采用什么样的缓存策略?
  • 我可以使用哪些免费工具来衡量和测试性能?我知道红门性能测量工具,但是许可证成本很高,所以免费工具是我更喜欢的.

如果这个问题太开放,我道歉.关于如何进行的任何提示或想法?

谢谢你的时间.

Dar*_*rov 4

设计可扩展应用程序时的一个重要考虑因素是使其无状态。没有会议。另一个重要的考虑因素是尽可能缓存所有内容,以减少数据库查询。并且这个缓存应该分布到其他专门设计来存储它的机器上。然后,当应用程序由于用户负载增加而开始运行缓慢时,您所要做的就是抛出一个额外的服务器。

至于您关于WCF的问题,您可以使用WCF,它不会成为您的应用程序的瓶颈。它肯定会添加一个额外的层,这会稍微减慢速度,但如果您想公开一个可以在其自己的 WCF 上独立扩展的可重用层,那就太好了。

ORM 确实可能会导致应用程序性能下降。这更多是因为您对生成的 SQL 查询的控制较少,因此更难以调整它们。这并不意味着您不应该使用 ORM。只需要小心它发出的 SQL 并与数据库管理员一起调整它。您还可以考虑一些轻量级 ORM,例如dapperPetaPocoMassive 。

就静态类而言,与实例类相比,它们不会提高太多性能。正如Ayende 所解释的那样,CLR 上的类实例化是一个相当快的操作。静态类将在数据访问层和消费层之间引入紧密耦合。所以你可以暂时忘记静态类。

对于错误日志记录,我建议您ELMAH

用于基准测试的工具有很多,Apanche Bench是一种易于使用的工具。

  • @user20358,如果您想构建可扩展的应用程序,这是您必须接受的一个缺点。为了在页面之间传递数据,HTTP 协议中有许多其他技术。例如查询字符串、HTTP POST 动词等...但没有会话。会话是可扩展性的大敌。是的,可以使用 ab.exe 对任何类型的应用程序进行基准测试。ab.exe 采用 url 作为参数,该 url 可以是任何内容。 (3认同)