的5个性能问题 不可忽视的应用

实施有效的APM战略面临的挑战：

过度的代码依赖或不必要的日志同步和锁潜在的数据库问题潜在的基础设施问题。

1、代码依赖

开发程序是一项具有挑战性的任务。你不仅要构建满足业务需求的程序逻辑，还要选择最合适的代码库和工具来帮助你。你能想象创建所有的日志管理代码、XML和JSON解析逻辑，或者所有的序列化库吗？当然，您可以编写代码来完成这些事情，但是许多开源开发团队已经完成了这些事情，那么您为什么要自己做呢？另外，如果是与第三方系统集成，是自己阅读专有的通信协议规范，还是购买供应商提供的库帮助自己完成？

我相信你会同意，如果有人已经解决了你的问题，使用他的解决方案会比试图自己解决更有效。如果这是一个已经被许多公司采用的开源项目，很可能它已经经过了彻底的测试和文档化，您应该会发现许多教程。

然而，使用依赖库是危险的。您需要回答以下问题：

这个库真的写得很好，测试充分吗？您是否像许多公司一样使用这个库？你的用法正确吗？在选择外部图书馆之前，一定要做一些调查。如果您对库的性能有任何疑问，请进行一些性能测试。开源项目最大的好处是你可以访问它们的所有源代码、测试套件和构建过程。下载它们的源代码，执行编译过程，并查看测试结果。如果你看到高测试覆盖率，你会比没有测试用例更有信心！

最后，确保依赖关系库被正确使用。如果使用得当，ORM工具可以大大提高性能。ORM工具的问题是，如果你不花时间学习如何正确使用它，你将很容易自食其果，破坏你的应用程序性能。关键是，如果你不花时间学习这些工具，那些应该对你有帮助的工具反而会伤害你。

2、过度或不必要的日志

日志是调试工具库中强大的武器，可以帮助您识别应用程序执行过程中特定时间内可能出现的异常。当发生错误时，捕获错误信息并收集尽可能多的上下文信息非常重要。然而，简洁地捕捉错误情况和过度记录是有区别的。

最常见的两个问题是：

多级异常日志错误配置生产日志级异常日志可以帮助您了解应用程序中的问题，因此非常重要。但是一个常见的问题是，应用程序所有级别的异常都被记录下来。例如，您的一个数据访问对象捕获一个数据库异常，并将该异常传输到服务层。服务层可以捕获异常并将其传输到网络层。如果我们在数据层、服务层和网络层记录异常，那么对于相同的错误情况，我们有三个堆栈记录。这将导致写入日志文件的额外负担，并且还会使日志文件充满冗余信息。但是这个问题很常见，我敢断言，如果你查看你的日志文件，你可能会发现很多这样的例子。

生产中另一个常见的日志问题与日志级别有关。那个。NET日志记录程序定义了以下日志记录级别(中的命名。NET TraceLevel和log4net会有所不同，但绝对相似):

关闭胎儿错误警告信息详细/调试在生产应用程序中，您应该只在错误或提取级别记录日志语句。在更宽松的环境中，绝对有可能在警告甚至信息级别捕获日志信息。但是，一旦应用程序投入生产，用户负载将很快填满日志并使应用程序瘫痪。如果不小心将生产环境中的应用程序日志级别设置为调试，那么应用程序的响应时间比正常情况高出两三倍也就不足为奇了！

00-1010有时，您希望确保应用程序代码中一次只有一个线程执行代码的子集。例如，读取共享软件资源(如单线程规则执行组件)和共享基础架构资源(如文件句柄或网络连接)。那个。NET framework提供了许多不同类型的同步策略，包括锁/监视器、进程间互斥以及读/写锁等特殊锁。

不管你为什么要同步代码，或者选择什么机制来同步代码，都会导致一个问题：有些代码一次只能由一个线程执行。想象一下去超市，只有一个收银员在工作：很多人进入商店，浏览商品并把它们放在购物车里，但在某个时候，他们不得不排队付款。在这个例子中，购物是多线程的，每个人代表一个线程。然而，结账是单线程的，这意味着每个人都必须花时间排队等待付款。这个过程如图1所示。

图1:线程同步。

我们有七个线程，它们都需要访问一个同步代码块，所以它们依次获得访问代码块的权限，执行它的功能，然后继续。

图2总结了线程同步的过程。

图2线程同步过程。

首先，为特定对象创建锁(从系统派生。对象)意味着当线程试图进入同步代码块时，它必须获取同步对象的锁。如果锁可用，线程被授予执行同步代码的权限。在图2的例子中，当第二个线程到达时，第一个线程已经占用了锁，所以第二个线程被迫等待，直到第一个线程完成执行。当第一个线程完成执行时，锁被释放，然后第二个线程被授予访问权限。

正如你可能猜到的，线程同步会给带来很大的挑战。NET应用程序。当我们设计一个应用程序时，我们希望它能够支持几十个甚至上百个同步请求，但是线程同步会序列化所有处理这些请求的线程，导致性能瓶颈！

有两种解决方案：

仔细检查同步代码，以确定是否有其他可行的方法来限制同步代码块的范围。有时，您需要访问必须同步的共享资源，但在许多情况下，您可以通过完全避免同步来再次解决问题。比如我们之前使用的常规进程引擎，有单线程的要求，降低了程序中所有请求的执行速度。这显然是一个设计缺陷，我们可以用一个可以并行工作的库来代替它。你需要问问自己是否有更好的选择：如果你正在将信息写入本地文件系统，你能把信息发送给服务，然后服务将信息存储在数据库中吗？你能不能把一个对象变成不可变的，这样它是否被多线程访问就不重要了？等等，等等.

对于那些必须同步的代码段，请合理选择锁。您的目标是隔离同步代码块，以满足最低同步要求。通常最好为同步定义一个特定的对象，而不是同步包含同步代码的对象，因为您可能会无意中减慢该对象的其他交互。最后，考虑使用读/写锁而不是标准锁，这样当资源只同步变化时，您就可以允许读操作。

3、同步与锁

几乎所有的内容应用程序最终都会涉及到从数据库或文档存储中存储/检索数据。因此，数据库、数据库查询和存储过程调优对于应用程序性能来说是最重要的。

程序架构师/开发人员和数据库架构师/开发人员之间有一个哲学上的划分。应用程序架构师倾向于认为所有的业务逻辑都应该驻留在应用程序中，数据库应该只提供对数据的访问。另一方面，数据库架构师倾向于认为将业务逻辑推入数据库更有利于提高性能。这个分歧的答案可能介于两者之间。

作为一名应用架构师，我倾向于将更多的业务逻辑应用到程序中，但我完全承认数据库架构师可以更好地理解数据以及与数据交互的最佳方式。在我看来，这两个团体之间的合作可以产生最好的解决方案。但是，无论您喜欢哪一方，请确保您的数据库架构师检查您的数据模型、所有查询语句和存储过程。他们有丰富的知识来帮助您以最佳的方式调整和配置数据库，并且他们有大量的工具来为您调整查询语句。例如，有可用于SQL优化的工具，请按照下列步骤操作：

分析SQL语句确定查询的执行计划，利用人工智能生成备选SQL语句确定所有备选的执行计划，提出实现目标的最佳查询方法。在编写数据库查询代码时，我使用了这种工具，并对高负载下的结果进行了量化。一些轻微的调整和优化可以带来巨大的性能提升。

如前所述

4.潜在的数据库问题

，NET应用程序在分层环境中运行，其分层结构如图3所示：

图3.NET分层执行模型。

您的应用程序运行在ASP.NET或Windows窗体容器中，并使用ADO库与运行在CLR内部的数据库进行交互，而CLR运行在操作系统中，而操作系统又运行在硬件中。硬件通过网络与包含不同技术栈的其他硬件连接。应用程序和外部环境之间以及应用程序的组件之间通常有多个负载平衡器。我们还有API管理服务和多级缓存。所有这些都是为了表明基础架构的数量如此之多，以至于可能会影响应用程序的性能！

因此，您必须仔细调整基础架构。检查应用程序组件和数据库的操作系统和硬件设备，以确保它们的最佳性能。测量服务器之间的网络延迟，并确保您有足够的带宽来满足应用程序之间的交互。检查缓存以确保高缓存命中率。分析负载平衡器的行为，以确保请求快速分发到所有可用的服务器。简而言之，您需要全面检查应用程序的性能，包括应用程序业务事务和支持它们的基础架构。