Django+Apache+Elastic Beanstalk架构下API响应缓慢排查求助

算力阿峰

2026-5-29

问题：Django POST API响应时间差异过大（内部耗时250ms vs 外部请求2.5s+）

我在Django中开发了一个POST API，并为应用安装了New Relic APM。Django处理请求耗时约250ms，但通过Postman测得的响应时间约为2.5秒。我的架构部署在AWS Elastic Beanstalk上：

使用带SSL的负载均衡器作为Web入口
Linux实例上运行Apache，通过WSGI部署Django应用

连续请求的响应时间在2.5秒到600ms之间波动，请问如何定位问题并将响应时间降至500ms以下？

我的Apache `http.d/wsgi.conf` 配置：

LoadModule wsgi_module modules/mod_wsgi.so
WSGIPythonHome /opt/python/run/baselinenv
WSGISocketPrefix run/wsgi
WSGIRestrictEmbedded On
<VirtualHost *:80>
    Alias /static/ /opt/python/current/app/static/
    <Directory /opt/python/current/app/static/>
        Order allow,deny
        Allow from all
    </Directory>
    WSGIScriptAlias / /opt/python/current/app/test_proj/wsgi.py
    WSGIPassAuthorization On
    WSGIPassAuthorization On
    WSGIPassAuthorization On
    <Directory /opt/python/current/app/>
        Require all granted
    </Directory>
    WSGIDaemonProcess wsgi processes=1 threads=15 display-name=%{GROUP} \
        python-home=/opt/python/run/venv/ \
        python-path=/opt/python/current/app:/opt/python/run/venv/lib64/python3.6/site-packages:/opt/python/run/venv/lib/python3.6/site-packages
        user=wsgi group=wsgi \
        home=/opt/python/current/app
    WSGIProcessGroup wsgi
</VirtualHost>
LogFormat "%h (%{X-Forwarded-For}i) %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

New Relic 统计数据截图
Postman 响应时间截图

排查与优化方案

从你的描述来看，Django内部处理耗时远低于外部请求总耗时，说明瓶颈大概率在Django之外的环节——比如负载均衡、Apache、WSGI配置、网络延迟或者AWS资源限制。下面是一步步的排查和优化建议：

1. 先清理Apache配置中的冗余项

你的wsgi.conf里重复了3次WSGIPassAuthorization On，虽然不影响功能，但先删掉重复配置，避免潜在的解析或优先级问题。

2. 排查负载均衡器层面的延迟

检查目标组健康检查配置：如果健康检查间隔过短、超时设置太小，可能导致负载均衡器频繁切换目标实例，引发请求波动。建议把健康检查超时设为5秒以上，间隔设为10-30秒。
查看CloudWatch负载均衡器指标：重点关注TargetResponseTime（实例返回给负载均衡器的时间）和RequestCount。如果TargetResponseTime接近Postman测的2.5秒，说明延迟在实例到负载均衡器之间；如果它接近Django的250ms，那延迟可能出在负载均衡器的SSL终止或公网传输环节。
优化SSL配置：强制启用TLS 1.2+，并选择高性能的SSL cipher套件（比如ECDHE-ECDSA-AES128-GCM-SHA256这类），减少SSL握手的耗时。

3. 优化WSGI进程/线程配置

你的WSGIDaemonProcess只设置了1个进程，意味着所有请求都挤在这一个进程里处理——当并发请求超过15个线程的上限时，后续请求会排队，这直接导致响应时间大幅波动。

建议调整为（根据你的实例CPU核心数调整，比如2核实例用4进程）：

WSGIDaemonProcess wsgi processes=4 threads=10 display-name=%{GROUP} \
    python-home=/opt/python/run/venv/ \
    python-path=/opt/python/current/app:/opt/python/run/venv/lib64/python3.6/site-packages:/opt/python/run/venv/lib/python3.6/site-packages
    user=wsgi group=wsgi \
    home=/opt/python/current/app

processes：建议设为实例CPU核心数的1-2倍，避免单进程瓶颈；
threads：每个进程10-20个线程足够，过多线程会增加上下文切换开销。

同时检查Apache全局配置的MaxRequestWorkers，确保它能容纳processes * threads的总并发数，避免Apache本身限制请求。

4. 验证静态资源处理逻辑

虽然你的接口是POST，但如果Apache误将某些请求转发给Django处理（而非直接返回静态资源），也会增加延迟：

访问一个静态文件，查看响应头的Server字段，确认是Apache直接处理的；
如果静态资源较多或较大，建议迁移到S3+CloudFront，用CDN加速静态资源，减轻Apache负载。

5. 深入追踪全链路耗时

用New Relic的Transaction Trace功能：查看请求从进入负载均衡器到返回的全链路时间分布，找到延迟最高的环节（比如Apache排队时间、网络传输时间）；
绕开负载均衡器直接测试：在EC2实例内部或通过实例公网IP调用API，如果响应时间接近250ms，说明问题在负载均衡器或公网；如果还是有延迟，就聚焦在实例内部的Apache/WSGI配置；
增强Apache日志：修改LogFormat添加%D（请求处理的微秒数），这样能看到Apache处理每个请求的总耗时，对比Django内部耗时，就能算出Apache的开销：
```
LogFormat "%h (%{X-Forwarded-For}i) %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined
```

6. 检查EC2实例的资源瓶颈

查看CloudWatch实例指标：重点看CPUUtilization（超过70%说明CPU不足）、MemoryUtilization（内存不足会触发SWAP，大幅增加延迟）、DiskIO（磁盘IO过高会拖慢所有操作）；
如果实例资源不够，考虑升级实例类型，或者增加实例数量做负载均衡。

7. 其他细节优化

启用Django的GZipMiddleware：对响应进行压缩，减少传输数据量，降低网络延迟；
检查POST请求体大小：如果请求payload过大，传输和解析时间会增加，建议优化数据格式或分块传输；
排查慢查询：虽然Django内部耗时250ms，但部分请求可能存在慢查询，用New Relic的Database板块或django-debug-toolbar（测试环境）排查。

内容的提问来源于stack exchange，提问作者Aakash

Django+Apache+Elastic Beanstalk架构下API响应缓慢排查求助

我的Apache http.d/wsgi.conf 配置： #

排查与优化方案 #

1. 先清理Apache配置中的冗余项 #

2. 排查负载均衡器层面的延迟 #

3. 优化WSGI进程/线程配置 #

4. 验证静态资源处理逻辑 #

5. 深入追踪全链路耗时 #

6. 检查EC2实例的资源瓶颈 #

7. 其他细节优化 #