想改善这个问题吗？更新问题，使其仅通过editing this post专注于一个问题。
6年前关闭。
如果将一个ASP.NET网站设计为可同时被许多用户（即10,000个用户）访问，则可以实现哪些技术，知识，方法，设计或实践？
您可以分享设计/实践的名称吗？我只需要知道这些技术的名称，即可继续在Google中进行进一步的研究。
谢谢。
最佳答案
这是一个巨大的话题-正如评论所说，没有神奇的子弹。
我将响应分为两个部分：体系结构和过程。
从体系结构的角度来看，有许多实践。首先，存在水平扩展-即您添加更多服务器，通常由负载均衡器管理。这是一个相对便宜的硬件解决方案，但是需要您知道瓶颈在哪里。横向扩展性最简单的技巧就是添加更多的Web服务器。使用分片等技术，水平扩展数据库服务器通常需要相当大的复杂性。水平缩放可以提高您的弹性和性能。
垂直可扩展性基本上意味着升级硬件-更多的RAM，更多的CPU，SSD磁盘等。这通常是最便宜的解决方案。这也可能意味着分离溶液的元素-例如将Web服务器与数据库服务器分开。
下一个架构解决方案是缓存-这本身就是一个巨大的话题。添加CDN是很好的第一步；许多CDN提供程序还提供“应用程序加速器”选项，这些选项可以有效地添加为反向缓存代理（非常类似于@Aviatrix的建议）。添加您自己的反向缓存代理通常是解决您自己环境中某些问题或从ASP.Net服务器上卸载静态文件服务的解决方案。
当然，ASP.Net在框架内提供了许多缓存选项-确保您阅读并理解它们；他们付出巨大的代价。另外，还要确保通过诸如YSlow之类的工具运行解决方案，以确保设置了适当的HTTP缓存头。
另一种可能会或可能不会有帮助的体系结构解决方案是异步调用外部服务。如果您的解决方案依赖于外部Web服务，则同步调用该服务基本上将您的站点限制在外部系统的容量和弹性上。对于高流量解决方案，这不是一个好主意。
为了获得非常高的可伸缩性，许多网站都使用NoSQL进行持久化-这是另一个巨大的话题，并且存在许多复杂的折衷。
从过程的角度来看，如果可扩展性是主要问题，则需要将其纳入开发过程。这意味着在整个项目中进行定期的性能和可伸缩性评估，并建立度量框架，以便您可以决定要进行的优化。
您需要能够对您的解决方案进行负载测试-但是在生产流量水平上进行负载测试通常在商业上是不现实的，因此您需要找到替代解决方案-我经常将JMeter与具有代表性的基础结构一起使用。您还需要能够找到负载下的瓶颈-这可能需要检测代码并使用探查器（RedGate做得很好）。
最重要的是要有一个评估权衡的过程-几乎每项性能/可扩展性的提高都以您关心的其他事情为代价。负载均衡器需要花钱；反向缓存代理解决方案增加了复杂性； NoSQL需要开发团队的新技能。 “聪明”的编码实践通常会降低可维护性。我建议您建立所需的基准，建立一个评估框架以根据该基准评估您的解决方案，并进行概要分析以找出瓶颈。每个提高可伸缩性的解决方案都必须解决当前的瓶颈，我建议进行概念验证阶段，以确保该解决方案确实具有预期的效果。
最后，对于现代硬件上的大多数Web应用程序，10000个并发用户并不是一个特别大的数目。
关于c# - 提高ASP.NET的性能，使其能够被许多用户访问，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/19110818/