终端用户总在抱怨应用迟钝，老板也为此苦恼。而这种压力，恰恰成为运维部门彻底修复应用的动力。可从哪儿着手呢?让我们先来分析一下最常见的五种导致应用缓慢的原因，然后再对症下药，找到并修复它们吧!

#1 客户端缓慢

问题：当今基于web的应用倾向于将用户交互工作(通常伴随大量数据)推送到客户端工作站。从那里，JavaScript代码会处理成百上千行的数据，而这些数据，在客户端显示更新前会导致数秒的停顿。

解决方案：借助高质量的应用性能管理(APM)系统，比如SteelCentral AppResponse，可以很轻松地发现具有此类内部处理延迟的客户端，并区分是应用暂停还是人类“思考时间”延迟。

#2 服务器缓慢

问题：服务器团队不喜欢听到应用性能缓慢是由服务器缓慢引起的这类指责，但是引起应用性能缓慢的最常见原因就是应用或服务器本身，而不是网络。

现代应用通常部署在多层基础设施上：

Ÿ前端Web服务器与应用服务器进行对话，应用服务器与查询一个或多个数据库服务器的中间件服务器进行对话

Ÿ然后，这些服务器都可能会与DNS服务器进行通信，以查找IP地址或将其映射回服务器名称上

当这种情况发生时，只有一个薄弱环节会使整个应用变慢。

解决方案：为了发现问题的根源，我们必须了解一个应用中多个组件之间的交互情况。这一过程被称作应用依赖关系映射(ADM)，用已有的监测解决方案所提供的信息作为APM集成方案的一部分。

幸运的是，网络为ADM提供了一个非常有利的位置，这意味着网络团队在很大程度上为应用和服务器团队提供帮助。但需要记住一点，借助数据包捕获工具来确定是网络还是应用的问题可能需要花费很多时间。

为了节省时间，某些领先的应用性能管理系统可以快速方便地找出导致应用性能迟缓的根源。一旦建立起适当的监测点和基本配置，就能即刻带来投资回报且便于使用。此外，收集到的信息还可以为APM软件提供了自动绘制关键应用依赖关系图所需的输入。

#3 小型数据库

问题：在带有小数据集的快速局域网上开发的应用在实验室中似乎运行得很顺利。然而，一旦投入生产网络，一切就都不复存在了。而且，随着数据库的不断增长，宕机时间也会不断加长。

解决方案：在此情况下，使用新型APM解决方案进行快速分析，可能会看到一个关键的中间件服务器正在多次向数据库服务器发出请求。实际上，只有一个客户端请求就可能会引发多个数据库请求或传输大量的数据。更简单高效的数据库查询通常能够解决这个问题。

在另一个实例中，数据库服务器可能需要花费几秒钟的时间才能将数据返回到中间件或应用服务器中。然后，应用团队可以使用APM系统来识别违规查询。

#4 频繁对话

问题：应用迟缓的另一个常见原因是频繁对话：一个应用服务器，或是客户端本身，会代表运行该应用的人员发出很多小的请求来执行一次交易。

然而，随着虚拟化技术的出现，服务器团队可能已经将服务器映像自动迁移到轻载主机。这可能会将服务器映像移动到远离其他服务器或磁盘存储系统几毫秒的位置。而且毫秒可以快速堆积。

解决方案：要解决此问题，需要掌握系统之间和系统连接到网络的请求数量，以及请求之间的延迟情况。

#5 网络服务迟缓

问题：最后，网络服务迟缓会降低应用性能，但这并不涉及到网络本身，而是大多数基于网络的应用所依赖的服务。

想象一个对不存在的主DNS服务器进行查询的应用。在没有响应的情况下，应用在尝试查询第二个DNS服务器之前必须超时第一个请求。在这种情况下，应用会周期性变慢，但却在其他时间运行良好。

解决方案：像这样的间歇性问题通常会很难诊断，但这却是像SteelCentral AppResponse这样的APM系统的用武之地，它能持续监测和记录所有交易。只需确定性能缓慢的时间，并找出数据中问题的根源，接下来修复它们只是分分钟的事。