我已经从 Heroku 迁移到了 Microsft Azure,速度真的很慢,我的应用程序服务具有以下规范的操作系统(linux):
P1V2
210 total ACU
3.5 GB memory
Dv2-Series compute equivalent
然后,当谈到我的Azure Database for PostgreSQL 灵活服务器时,以下是规范操作系统 (linux):
General Purpose (2-64 vCores) - Balanced configuration for most common workloads
由于 Redis 缓存,我的响应时间为 15 秒,有时会达到 30 秒或更长:
我确信所有这些规范都高于它过去提供的默认 Heroku 规范,但为什么我的 Django 项目在 API 请求的响应时间方面非常慢?
添加:
- 我使用的容器注册表会连接到有自动部署的应用服务。
- 我还修复了端点上的 n + 1 问题。
Always on
已打开,我读了几篇这样的帖子 one .
更新:
我有一个 ps
和 top
通过 bash 使用 Kudu,但我似乎没有看到任何 zomibe 进程,我还在按 ' 后用 S=Z 进行了搜索o',但我没有找到,下面是截图:
top - 16:31:58 up 1 day, 1:47, 1 user, load average: 0.36, 0.62, 0.48
Tasks: 7 total, 1 running, 6 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.9 us, 4.6 sy, 2.2 ni, 89.5 id, 2.4 wa, 0.0 hi, 0.5 si, 0.0 st
MiB Mem : 13993.7 total, 2266.7 free, 1967.4 used, 9759.6 buff/cache
MiB Swap: 2048.0 total, 2032.2 free, 15.8 used. 11719.2 avail Mem
最佳答案
导致响应时间过长的原因可能有多种,需要找出问题所在。请尝试以下步骤:
如果尚未完成,请启用“始终开启”功能。默认情况下,如果 Web 应用程序闲置一段时间,则会卸载它们。这可以让系统节省资源。在基本或标准模式下,您可以启用“始终开启”以使应用程序始终处于加载状态。
在应用服务应用程序的左侧导航栏中,点击
诊断并解决问题
– 查看“诊断工具”>“可用性和性能”和“最佳实践”。
将
扩展条件
的 CPU 利用率更新为 75%,或者将缩小条件的 CPU 利用率更新为 25% 作为测试,看看是否有任何差异(以避免波动
条件/我知道您已经分析过 CPU 使用情况)隔离/避免
出站 TCP 限制
更容易解决,因为限制是根据工作线程的大小设置的。您可以在 Sandbox Cross VM Numerical Limits - TCP Connections 中查看限制。 - - 为了避免出站 TCP 限制,您可以增加工作线程的大小,或水平扩展。Troubleshooting intermittent outbound connection errors in Azure App Service -(隔离端口耗尽)。
如果单个应用服务计划下有多个应用,请将应用
分布到多个应用服务计划
以获得额外的计算级别(以进一步隔离问题/共享有关此问题的更多详细信息)在下面的“评论”部分)
查看日志
以获取有关此问题的更多详细信息。
注意:Linux 目前是在应用服务中运行 Python 应用的推荐选项,我相信您正在利用应用服务 Linux 风格。
关于python-3.x - Django Rest Framework 在 Azure 上非常慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/74769756/