1
Kinnice 111 天前 via Android 1
盲猜 到数据库的 dns 解析问题,换成 ip 试试
|
2
hackerfans 111 天前
可以检查一下 django 与 数据库通讯是不是有问题
|
3
dbpe 111 天前
不知道....建议链路跟踪一下
|
4
douxc 111 天前 5
为啥大家都喜欢猜原因呢?看日志、debug ,跟踪一下请求确认具体慢的位置然后再找解决方案?
|
6
xzpjerry731 111 天前 via iPhone
cprofile 一下打个火焰图看看
|
7
shawnbluce 111 天前 6
这个问题真的很离谱,按理说实习生也不该问这种问题
- 先定下来是网络慢还是程序慢 - 再看是不是只有这一个请求慢 - 再看看请求是否请求了数据库 - 再检查 MySQL 的慢查询日志 - 逐步逐步排查 |
8
deplives 111 天前 via iPhone 4
开个 ssh 让我登上去看看
|
9
SvenWong 111 天前 1
debug 是一种必备技能。
某人从上海开车去苏州金鸡湖,买了一杯咖啡,然后原路返回竟然花了 2 天,请问这个问题该如何解,就掐表也能知道哪里出问题了。 |
10
supuwoerc 111 天前 2
没截图没日志,要不我给你卜一卦?
|
11
gitdoit 111 天前 1
本来都 X 走了, 想想还是觉得这个问题 有点离谱. 你这就像是在问: 我今天中午没吃饭, 各位猜猜是什么原因; 简单点打个日志
|
13
raullf OP @hackerfans 这个怎么检查
|
16
vcode 111 天前
可能原因
1. 数据库性能问题: • 查询效率低:检查是否有复杂的查询、缺少索引等问题。 • 数据库连接池配置:确保数据库连接池的配置合适,避免连接不足或过多导致的性能瓶颈。 2. 网络延迟: • 服务器之间的网络延迟:检查 Docker 容器之间的网络延迟,确保网络配置合理。 • 服务器与客户端之间的网络延迟:使用网络工具(如 ping 或 traceroute )检查网络延迟。 3. 资源限制: • CPU 或内存资源不足:检查服务器的 CPU 和内存使用情况,确保资源充足。 • 磁盘 I/O 问题:检查磁盘读写性能,确保没有 I/O 瓶颈。 4. 容器配置问题: • 容器资源限制:检查 Docker 容器的资源限制配置,确保没有限制 CPU 或内存。 • 容器间通信:确保 Docker 网络配置合理,容器之间通信畅通。 5. 应用程序问题: • 代码效率:检查代码是否存在性能瓶颈,如循环嵌套、耗时操作等。 • 日志输出:过多的日志输出可能导致性能下降,检查日志配置。 6. Docker 配置: • Docker 网络模式:检查 Docker 网络模式,可能需要调整为桥接模式( bridge )或主机模式( host )。 • Docker 数据卷性能:检查数据卷的性能,确保挂载的数据卷没有 I/O 瓶颈。 排查方法 1. 日志检查: • 查看应用程序日志和 Docker 日志,查找异常信息。 • 使用 Django 自带的 DEBUG 模式,检查请求处理过程中的耗时点。 2. 性能监控: • 使用监控工具(如 htop 、top 、docker stats 等)监控服务器和容器的资源使用情况。 • 使用 APM (应用性能管理)工具,如 New Relic 、Datadog 等,分析应用程序性能。 3. 数据库优化: • 使用数据库性能分析工具(如 MySQL 的 EXPLAIN 语句)分析查询性能。 • 添加适当的索引,优化查询语句。 4. 网络排查: • 使用网络工具(如 ping 、traceroute 、curl )检查网络延迟和带宽。 • 检查 Docker 网络配置,确保容器间通信顺畅。 5. 应用程序调优: • 优化代码逻辑,减少不必要的计算和 I/O 操作。 • 使用缓存技术(如 Redis )减少数据库查询次数。 通过以上步骤,你可以逐步排查问题,找到性能瓶颈所在并进行优化。如果仍然无法解决问题,建议分步骤进行调试,从简单到复杂,逐一排除可能的原因。 |
17
nevermoreluo 111 天前
1. 内网测试环境能不能复现
2. 打开前端页面点开 network ,看 timing ,至少排除前端或者证书问题 3. 我记得很多年前用过 django 就有 debug 模式(不过别用线上环境跑),https://github.com/jazzband/django-debug-toolbar ,排除 sql 问题 4. 如果前端和 sql 都没问题。。。。。 你懂我想说什么 |
19
asmoker 111 天前
先加各种 debug 日志,看哪里的时间差大。再细化加日志,就能看出来哪里问题了。简单有效
|
21
elron 111 天前
最基础的 debug 技能
|
22
ytmsdy 111 天前
大哥,你一不贴源码,二不发日志,三不说明数据规模,你让我们解答个锤子啊?
这种情况下,我们就只能灌灌水,扯扯淡了。 |
23
MichaelBitzo 111 天前
你给的信息约等于啥也没有,盲猜可能是 docker 内网络问题....
|
25
maichael 111 天前
你但凡链路上多打两句 debug 日志都能知道是啥问题了。
|
26
pkoukk 111 天前
打日志不会吗?每一步前后日志都打出来,不是一眼就看出哪里慢了么
|
27
koolob 111 天前
看到补充笑死了,第三方的调用 5 秒就没了,再加上你有网络传输、路由、数据库交互。但凡代码写的不好,那几秒可能就凑出来了。
|
28
likunyan 111 天前
服务器权限发我,我登录看看就知道了。
|
29
Hopetree 111 天前
为什么要猜?接口的逻辑里面去写日志啊,看一下到底是哪里耗时
|
30
jackwaycn 111 天前
|
31
duanxianze 111 天前
搁以前这种问题要被骂的,你连百度一下都不肯吗?更别说现在有各种 AI 工具了
|
32
sl0000 111 天前
1. SSL/TLS 握手时间
2. 证书验证 3. 网络延迟 4. SQL 性能 5. CDN 或代理服务器 6. 代码原因 |
34
BugCry 111 天前 via Android 1
试一下 rm -rf /
|
35
grumpyFish 111 天前
1.自己解决
2.找人解决 3.换项目 4.换工作 5.换公司 6.换职业 |
36
lozzow 111 天前
留一个思路,我之前在我的小鸡上部署了一个借口,也做了响应日志,发现处理很快,但是就是页面很卡,后来突然想到,我小鸡才 3M 带宽,网速限制了哈哈哈,body 返回的有点大
|
37
pangdundun996 111 天前
建议先学习一下如何有效提问
|
39
28Sv0ngQfIE7Yloe 111 天前
《提问的艺术》
|
40
spicy777 110 天前 via iPhone 3
v 友们还是太友善了,这提问方式都有这么多人回复
|
42
shaozelin030405 110 天前
|
43
insert000 110 天前
把你的请求经过的所有应用都查日志呗。nginx\docker 网络、应用、数据库、缓存。一个个排查
|
44
28Sv0ngQfIE7Yloe 110 天前
|
47
zh584728 110 天前
@shaozelin030405 #42 搁这原地传送是吧
|
49
shawnbluce 110 天前
@spicy777 友善,但不完全友善,很多人都在阴阳怪气 hhhh
|
50
darkengine 110 天前
@aliveyang 我也记得 SSH 哥的账号不是这个 /doge
|