我正处于中型asp.net c＃项目的开端，并且具有应用程序性能要求，能够支持大约400多个并发用户。
在构建满足此类性能和可用性标准的应用程序时，我需要记住哪些事项？该页面需要在5秒内完成。我计划将应用程序和数据库放在不同的物理机器上。从编码和应用程序分层的角度来看： -
如果这个问题太开放，我道歉。关于我应该如何进行的任何提示或想法？
感谢您的时间。
答案 0 :(得分：4)
设计可伸缩应用程序时的一个重要考虑因素是使其无状态。没有会议。另一个重要的考虑因素是缓存所有可以减少数据库查询的内容。此缓存应分发给专门设计用于存储它的其他计算机。然后，当应用程序由于用户负载增加而开始缓慢运行时，您所要做的就是抛出一个额外的服务器。
就您对WCF的问题而言，您可以使用WCF，它不会成为您的应用程序的瓶颈。它肯定会添加一个额外的层，这会让事情变得缓慢，但如果你想暴露一个可以在自己的WCF上独立扩展的可重用层，那就太棒了。
ORM可能确实会在您的应用程序中引入性能下降。这更多是因为您对生成的SQL查询的控制较少，因此更难以调整它们。这并不意味着您不应该使用ORM。它只是要小心它吐出的SQL，并用数据库管理员调整它。您还可以考虑使用轻量级ORM，例如dapper，PetaPoco和Massive。
就静态类而言，与实例类相比，它们不会提高性能。 CLR上的类实例化是一个非常快速的操作Ayende explains。静态类将在您的数据访问层和消费层之间引入紧密耦合。所以你暂时可以忘记静态类。
对于错误记录，我建议您ELMAH。
对于基准测试，有很多工具，Apanche Bench是一个易于使用的工具。
答案 1 :(得分：2)
在开发人员的工作效率，可维护性和性能之间总是需要权衡;如果你可以测量，你只能真正做出明智的权衡。生产力是通过完成某项工作所需的时间来衡量的;可维护性难以衡量，但幸运的是，性能相当容易量化。总的来说，我会说首先要优化生产力和可维护性，并且只有在遇到可测量的问题时才优化性能。
要以这种方式工作，您需要有性能目标，并且需要定期评估针对这些目标的解决方案 - 将性能改进到项目中非常困难。但是，在没有经过验证的必要性的情况下优化性能往往会导致模糊，难以调试的软件解决方案。
首先，您需要将性能目标转换为可以衡量的数字;对于Web应用程序，通常是“每秒动态页面请求”。 400个并发用户可能并非都在同一时间请求页面 - 他们通常花一些时间阅读页面，填写表单等。另一方面，AJAX驱动的站点请求更多动态页面。
根据等待时间，每次交互的请求以及缓冲区内的构建，使用Excel或其他东西从峰值并发用户到每秒动态页面生成 - 我通常超额配置50％。
例如：
400个并发用户，会话长度为5次交互 每次交互2个动态页面意味着400 * 5 * 2 = 4000个页面请求。
等待时间为30秒，这些请求将分布在30 * 5 = 150秒内。
因此，您的平均页面请求数/秒是4000/150 = 27个请求/秒。
使用50％的缓冲区，您需要能够支持大约40个请求/秒的峰值。
这不是微不足道的，但绝不是例外。
接下来，设置一个性能测试环境，其特性是您完全理解并可以复制的，并且可以映射到生产环境。我通常不建议在此阶段重新制作作品。相反，减少您的页面生成/秒基准以匹配性能测试环境（例如，如果您在生产中有4台服务器，在性能测试环境中只有2台，减少一半）。
一旦开始开发，定期（至少每周一次，理想情况下每天一次）将您正在进行的工作部署到此测试环境中。使用负载测试生成器（Apache Benchmark或Apache JMeter为我工作），编写模拟典型用户旅程的负载测试（但没有等待时间），并针对您的性能测试环境运行它们。通过达到目标“页面世代/秒”基准来衡量成功。如果你没有达到基准，找出原因（Redgate的ANTS探测器是你的朋友！）。
一旦接近项目的最后，尝试在基础设施方面获得更接近生产系统的测试环境。部署您的工作，并重新运行您的性能测试，增加负载以反映“真实”页面/第二个要求。在这个阶段，您应该很好地了解应用程序的性能特征，因此您实际上只是验证了您的假设。获得这样一个“类似生产”的环境通常要困难得多，而且成本也要高得多，而且对软件进行更改通常要困难得多，所以你应该纯粹用它来验证，而不是做常规的性能工程。