Microsoft.NETFramework是最流行的应用程序开发平台和编程语言之一。C#和ASP.NET框架已被数百万开发人员用来构建Windows客户端应用程序、XMLWeb服务、分布式组件、客户端-服务器应用程序、数据库应用程序等。随着.NET应用程序的应用越来越广泛，保证.NET应用程序的良好性能是大多数应用程序所有者和开发人员最重要的需求。.NET应用程序运行缓慢的原因有很多。其中包括不正确的内存大小、GC暂停、代码级错误、过多的异常记录、同步块的高使用率、IIS服务器瓶颈等等。在此博客中，我们将研究.NET应用程序中的一些常见性能问题，并提供故障排除和解决这些问题的技巧。1.未处理的异常与过多的异常记录.NET异常不是坏事，只是错误的使用才是。大多数开发人员都相信，如果异常处理得当，即抛出、捕获和处理（而不是忽略），它将带来稳定的性能。然而，就像太多的厨师会破坏汤一样，太多未处理的异常会导致代码效率低下并影响应用程序性能[1]。隐藏的异常尤其糟糕，就像雷区一样，如果不检查它们，它们会影响页面加载时间。.NET的另一个问题是异常记录过多。日志记录可以成为调试工具库中的一个很好的工具，用于识别在处理应用程序时记录的异常。但是，当日志记录设置为在应用程序架构的每一层捕获异常时，您最终可能会在Web、服务和数据层记录相同的异常。这会增加应用程序代码的负担并增加响应时间。在生产环境中，只有致命事件和错误需要小心记录。记录所有信息，包括信息性消息、调试和警告，很容易使您的生产日志文件膨胀，进而影响代码处理。有用的故障排除提示：确保您的C#代码有一个“try-final-catch”块来处理异常。利用C#6及更高版本中可用的异常筛选器，它允许为每个catch块指定条件子句以检查空值，并使用TryParse来避免潜在的异常。小心第二次机会的异常，因为它们表明发生了第一次机会的异常并且未正确处理。使用异常处理和日志记录库（例如EnterpriseLibrary、NLog、Serilog或log4net）将异常记录到文件或数据库。确保仅在需要时记录异常，并且不会最终导致日志文件膨胀。2.过度使用线程同步和Lock.NETFramework提供了很多线程同步选项，比如进程间互斥锁，reader/writerlock等。有时候.NET开发者会写这样的代码，只能服务一个线程在给定条件下。时间和其他要处理的并行线程将不得不在队列中等待。例如，结帐应用程序应根据其业务逻辑一次处理一个请求。同步和锁定有助于序列化传入线程以供执行。通过创建同步代码块并在特定对象上加锁，传入线程需要等待，直到同步对象上的锁可用。虽然此策略在某些情况下可能会有所帮助，但不应过度使用。有用的故障排除提示：使用同步编码并仅在必要时使用锁。在决定使用锁之前，了解您的代码执行需求。优化调整锁的持续时间范围，以便它们延迟获取并提前释放，并且不会长时间等待其他线程。要减少并发问题，请考虑使用松散耦合。事件委托模型也可用于最小化锁争用。使用代码分析工具[2]监控.NET代码，以确定线程锁是否导致应用程序处理缓慢。3.当应用程序挂起并且有时特定URL很慢时，这是一回事。但是，当IIS网站挂起并且所有或大部分页面永远加载时，情况并没有变得更糟。通常，当应用程序过载或死锁时，可能会发生挂起。.NET应用程序通常会遇到两种类型的应用程序挂起情况。硬挂起（IIS问题）：这通常发生在请求处理管道的开头——请求排队的地方。由于应用程序死锁，所有可用线程都可能被阻塞，导致后续传入请求最终进入队列等待服务。当活动请求数超过IIS服务器上配置的并发限制时，也会发生这种情况。此类挂起将表现为请求超时并收到503ServiceUnavailable错误。Hard影响所有URL和整个Web应用程序本身。有用的故障排除提示：跟踪IIS服务器队列中的请求数（Windows性能监视器中的HttpServiceRequestQueues\ArrivalRate）。这不得超过为工作进程配置的请求处理限制。还跟踪队列中的请求等待时间（Windows性能监视器中的Http服务请求队列\MaxQueueItemAge）。这将有助于检测应用程序是否面临潜在的挂起。还可以通过监视IIS服务器事件来注意服务不可用和连接超时错误。软挂起（ASP.NET问题）：这通常是由特定段的应用程序代码中的错误引起的，只影响少数网址而不影响整个网站。通常，由ASP.NET控制器或页面引起的挂起发生在ExecuteRequestHandler阶段。要确认这一点，您可能需要查看调试器以了解请求卡住的确切位置。检查模块名称、阶段名称和URL。该URL将指示导致挂起的控制器/页面。有用的故障排除提示：通过检查Windows性能监视器中的Http服务请求队列\CurrentQueueSize计数器来验证IIS是否是问题所在。如果为0，则IIS没有排队的请求。如果不是IIS问题，则它一定是ASP.NET控制器/页面中的代码级问题。使用任何代码分析来确定哪些URL挂起并获取详细的请求跟踪。验证请求挂起的模块名称和阶段名称，以确认这是一个ASP.NET问题。使用事务跟踪工具[3]的代码分析可以帮助确定有问题的确切代码行。4.频繁的垃圾收集暂停.NETCLR中的垃圾收集(GC)是在托管堆上分配的对象使用的内存超过应用程序开发人员配置的可接受阈值时启动的。这是GC.Collect方法开始行动并回收死对象占用的内存的时候。CLR中的GC通常发生在存储短期对象的第0代堆上。当GC发生在包含长寿命对象的第二代堆中时，称为FullGC。每次GC发生时，它都会在CLR上增加大量CPU负载并减慢应用程序的处理速度。因此，如果GC暂停时间更长且更频繁，应用程序将趋于变慢。有用的故障排除提示：适当调整GC堆内存的大小，并确保根据需要设置GC限制。避免在不需要的地方使用对象和大字符串。跟踪GC实例、GC花费的时间以及JVM花费的GC时间百分比。寻找何时发生完整的GC。这可能会导致应用程序变慢。根据应用程序需要明智地使用服务器GC或工作站GC。对CLR层进行端到端监控，以识别内存使用情况、GC活动、CPU峰值等。5.IISServerBottleneckMicrosoftIISServer是.NETFramework的关键部分。IIS是托管基于.NET构建的Web应用程序或网站的Web服务器，并运行W3WP进程，该进程负责响应传入的请求。IIS还集成了公共语言运行库(CLR)，后者负责为线程分配资源。由于IIS具有各种移动部件，IIS中的瓶颈会对.NET应用程序性能产生直接的负面影响。常见的IIS服务器问题：由于过度使用内存、CPU等资源导致服务器过载高并发和连接丢失不正确的HTTP错误，包括静态和动态内容错误以及连接错误没有资源争用或资源过度利用。根据传入请求的速率与更多IIS服务器进行负载平衡。跟踪SSL证书的有效性并在证书过期之前主动收到警报。监控IIS性能[4]、应用程序池、网站[5]的所有方面，并识别不正确的配置和性能偏差。6.缓慢的数据库查询并不总是影响应用程序性能的.NET代码问题。运行缓慢的查询通常是常见的原因。但通常是.NET应用程序开发人员应为应用程序性能下降负责[6]。这样做的原因是没有关于SQL性能如何影响.NET应用程序处理的上下文可见性。ADO.NET和ODP.NET连接问题可能是查询处理缓慢的原因之一，但一个常见的原因是查询格式不正确。不正确的执行计划、缺失的索引、不正确的模式设计、小的缓冲池、缺失的连接、不正确的缓存、不正确的连接池等也是影响数据库查询处理的原因。DBA负责数据库性能和查询创建，而.NET应用程序所有者需要在应用程序处理期间跟踪查询级别的问题。这将有助于区分代码级问题和数据库问题，并且.NET开发人员不必花时间在他们的代码中寻找问题。有用的故障排除提示：在应用程序事务的上下文中监视查询处理以识别慢速查询。正确规划数据库的大小和配置以确保一致的性能。使用数据库监控工具[7]来识别和修复丢失的索引，通过重建索引优化数据库布局等。跟踪数据库与应用程序的连接以隔离任何连接问题。温馨提示：速度慢除了数据库调用速度慢外，还有可能是外部调用[8]（如HTTP、WebService、WCF）[9]造成的。7.Infrastructurefailure：虽然不是.NETFramework的问题，但还是.NET的问题！.NETFramework不是一个单独的层。使用.NETFramework的应用程序将对基础设施有许多依赖性，例如任何虚拟服务器、容器或云基础设施。然后，可能会有后端存储设备。尽管这些不是直接的.NET问题，但任何这些基础结构组件的问题同样会影响.NET性能。就像我们已经看到IIS服务器和数据库可能会出现瓶颈，VM可能会耗尽资源，SAN阵列可能会遇到它们无法处理的高IOPS，或者如果.NET应用程序托管在Azure上，则可能有一个应用程序服务运行不正常。在大多数应用程序环境中，与网络相关的投诉位居榜首。无论是网络问题还是应用程序问题，总是存在相互指责的博弈。网络拥塞、数据包丢失或设备故障会影响应用程序性能和连接性。有用的故障排除提示：.NET应用程序环境的整体性能保证需要对应用程序和支持基础结构之间的依赖关系的相对可见性。确保实施融合的应用程序和基础架构监控策略以发现基础架构问题。当您专注于捕获和修复所有这些问题时，请务必记住，编写干净高效的代码可以解决.NET端的许多问题。编写好的代码，保持系统和基础设施健康，并实施必要的工具来监控自动化。这将帮助您交付高性能.NET应用程序和数字体验。参考资料[1]应用性能：https://www.eginnovations.com/blog/what-is-application-performance-monitoring/[2]代码分析工具：https://www.eginnovations.com/microsoft-net-监控[3]事务跟踪工具：https://www.eginnovations.com/microsoft-net-monitoring[4]监控IIS性能：https://www.eginnovations.com/iis-monitoring[5]各方面，：https://www.eginnovations.com/iis-monitoring[6]应用程序性能下降：https://www.eginnovations.com/webinar/my-application-is-slow-troubleshooting-prevention/[7]数据库监控工具:https://www.eginnovations.com/database-monitoring[8]除了慢之外，由于外部调用：https://img.ydisp.cn/news/20220902/b5wol54gaoc速度慢：https://img.ydisp.cn/news/20220902/3vmiyw32uja
