上次更新日期：2020 年 10 月 2 日
当我尝试访问在 Application Load Balancer 后注册的目标上运行的 Web 应用程序时，遇到高延迟和超时问题。我应该如何解决这些问题？
简短描述Application Load Balancer 上出现高延迟的可能原因包括：
网络连接问题 后端实例上的高内存 (RAM) 利用率 后端实例上的高 CPU 利用率 后端实例上的 Web 服务器配置不正确 在后端实例上运行的 Web 应用程序依赖性问题，例如外部数据库或 Amazon Simple Storage Service (Amazon S3) 存储桶 解决方法1.按照排查 Application Load Balancers 问题中的故障排查步骤检查网络连接问题。
2.使用 curl 测量第一个字节响应，并检查 DNS 解析缓慢是否是造成延迟的原因。
curl -kso /dev/null https://www.example.com -w "==============\n\n
| dnslookup: %{time_namelookup}\n
| connect: %{time_connect}\n
| appconnect: %{time_appconnect}\n
| pretransfer: %{time_pretransfer}\n
| starttransfer: %{time_starttransfer}\n
| total: %{time_total}\n
| size: %{size_download}\n
| HTTPCode=%{http_code}\n\n" ; done示例输出：
| dnslookup: 0.005330
| connect: 0.006682
| appconnect: 0.026540
| pretransfer: 0.026636
| starttransfer: 0.076980
| total: 0.077111
| size: 12130
| HTTPCode=200通过 Application Load Balancer 执行这些测试。然后，在绕过至目标的 Application Load Balancer 时执行测试。此方法有助于隔离导致延迟的组件。
3.检查您的 Application Load Balancer 的 Amazon CloudWatch TargetResponseTime 指标的平均统计数据。如果值很高，则后端实例或应用程序依赖性服务器可能存在问题。
4. 通过检查 Application Load Balancer 的访问日志条目确定哪些后端实例遇到高延迟问题。检查 target_processing_time 以查找具有延迟问题的后端实例。此外，请查看 request_processing_time 和response_processing_time 字段，以验证 Application Load Balancer 是否出现任何问题。
5. 针对您的后端实例查看 CloudWatch CPUUtilization 指标。查找高 CPU 利用率或 CPU 利用率的峰值。要获得较高的 CPU 利用率，请考虑将实例升级为更大的实例类型。
6.通过查看后端实例上的 Apache 进程来检查内存问题。
示例命令：
watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"示例输出：
Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no-
headers | wc -1 && free –m
Apache Processes: 27
total used free shared buffers cached
Mem: 8204 7445 758 0 385 4567
-/+ buffers/cache: 2402 5801
Swap: 16383 189 161947.检查您的后端实例上的 Web 服务器的 MaxClient 设置。此设置定义了实例可以同时处理的请求数量。对于适当的内存和 CPU 利用率遇到高延迟的实例，请考虑增加 MaxClient 值。
比较 Apache (httpd) 生成的进程数与 MaxClient 设置。如果 Apache 进程的数量经常达到 MaxClient 值，请考虑增加该值。
# ps aux | grep httpd | wc -l 15<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 10
ServerLimit 15
MaxClients 15
MaxRequestsPerChild 4000
</IfModule>8.检查可能导致延迟问题的后端实例的依赖性。依赖关系可能包括共享数据库或外部资源（例如 Amazon S3 存储桶）。依赖关系还可能包括外部资源连接，例如网络地址转换 (NAT) 实例、远程 Web 服务或代理服务器。
9. 使用以下 Linux 工具来确定服务器上的性能瓶颈。
正常运行时间 – 显示负载平均值，以帮助确定等待运行的任务（进程）数。在 Linux 系统上，此数字包括等待在 CPU 上运行的进程，以及在不间断 I/O（通常是磁盘 I/O）中被阻止的进程。此数据提供必须使用其他工具解释的资源负载（或需求）的高级视图。当 Linux 负载平均值增加时，对资源的需求也会增加。要确定哪些资源需求较高，您必须使用其他指标。例如，对于 CPU，您可以使用 mpstat -P ALL 1来测量每个 CPU 的利用率，或使用 top 或 pidstat 1 来测量每个进程的 CPU 利用率。
mpstat -P ALL 1 – 显示每个 CPU 的 CPU 细分时间，您可以用它来检查不平衡性。单个热 CPU 或许是某个单线程应用程序的证据。
pidstat 1 – 显示每个进程的 CPU 利用率并打印滚动摘要，这对于长期观察模式非常有用。
dmesg | tail – 显示最后 10 条系统消息（如果有）。查找可能导致性能问题的错误。
iostat -xz 1 – 显示应用于数据块设备（磁盘）的工作负载及产生的性能。
free -m – 显示可用内存量。检查并确认这些数字的大小不接近零，这可能会导致磁盘 I/O 提高（使用 iostat 确认），性能下降。
sar -n DEV 1 – 将网络接口吞吐量（rxkB/s 和 txkB/s）显示为工作负载的衡量指标。检查是否已达到任何限制。
sar -n TCP,ETCP 1 – 显示关键 TCP 指标，包括：active/s（每秒钟在本地启动的 TCP 连接数）、passive/s（每秒钟远程启动的 TCP 连接数）和 retrans/s（每秒钟的 TCP 重新传输次数）。
iftop – 显示服务器与使用带宽最多的远程 IP 地址之间的连接。n iftop 提供在一个软件包中，该软件包在基于 Red Hat 和 Debian 的发行版中具有相同的名称。但是，在基于 Red Hat 的发行版中，您可能会在第三方存储库中找到 n iftop。</p