作者antonio9033 (菩提本无物)
看板MIS
标题[Case] 企业内网_网站点击查询後等待时间过长
时间Fri May 20 11:41:23 2022
[▂事情是这样的
最近接到一个issue是关於server更换实体位置放置後，
User端开始有感网页操作的回应时间变长了。
========详情========
一台挂有外包网页系统的server，原本放在 B栋 lab，多数使用者也在lab，
user操作上存取回应很快，由 A/B栋连线，各种动作都是1s内完成。
由於前几个月的台电停电，此server被规画至另一UPS区域 C栋放置，问题就开始了..
需要查询DB的步骤，由 A/B栋连线过去，从原本的1s内，拉长为3~4s，
导致一天有数百笔资料要处理的lab user开始抱怨了。
========环境========
企业内网
光纤 光纤
A ---------- B ---------- C(server现存位置)
(Switch 1G) (Switch 1G)
B/C栋的光纤是由A栋拉过去的
而中间介面是一台1G的Swtich
========测试========
目前实测，A/B栋(透过Switch 1G出去)连到C栋的都是3~4s，
但在C栋内找了数台装置测试，仍维持在1s内的回应!
ping值也都在1~2ms TTL=128也正常。
========问题========
在此情况下，还有什麽方式能够测试，以判断是设备效能不足抑或是网速不足导致的问题?
(因为在同一网段内回应时间是1s内，暂时排除网页系统效能问题。)
先感谢大家拨冗阅读 (_"_)
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 116.50.60.180 (新加坡)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/MIS/M.1653018103.A.EF1.html
1F：推 asimon: 先F12的Network看看到底卡在哪个环节？C栋有其他AB连正常 05/20 12:49
2F：→ asimon: 的服务吗？ 05/20 12:49
3F：→ kojj: 你先列出你手上设备的软硬体清单，看那些可以监控，以及怎做 05/20 13:40
4F：→ antonio9033: F12确认过，秒数都花在[时间]页签内(要求/回应)中的 05/20 14:25
5F：→ antonio9033: 已传送要求 ===>2.3毫秒 05/20 14:25
6F：→ antonio9033: 等待(TTFB) ====>859.09毫秒 05/20 14:26
7F：→ antonio9033: 下载内容 =====>282.33毫秒 05/20 14:26
8F：→ antonio9033: 更正:已传送要求====>2.30 秒 05/20 14:27
9F：→ antonio9033: 目前尴尬的是，C栋只有这个对外的service，无法比较 05/20 14:29
10F：→ antonio9033: >>kojj 好的 硬体是网路设备，那软体需要列哪些呢? 05/20 14:50
11F：推 McAfee: 前阵子公司前辈有处理类似的 有听到好像是从DNS方面下去 05/20 15:49
12F：→ McAfee: 查而解决 05/20 15:49
13F：→ kojj: 你OS? DB? Web service? 以及你有多少权限做设定与监控? 05/20 17:21
14F：→ kojj: 看你刚回报数字，比较像你服务平台的延迟造成，但是原因.... 05/20 17:23
15F：→ kojj: 859ms 那值太慢，但原因可能很多，要看你的最大负载在哪 05/20 17:26
16F：→ jenhsiangyu: 这样怎麽感觉Switch 的forwarding有出现问题？ 或者g 05/20 21:21
17F：→ jenhsiangyu: bic 没有接好等可能，如果是我我会从switch 上开始盘 05/20 21:21
18F：→ jenhsiangyu: 查问题 05/20 21:21
19F：推 chang505: 跨网域的先看是不是 db query 回圈过多，handshake 会 05/21 10:35
20F：→ chang505: 花很多时间 05/21 10:35
21F：→ chang505: 还有就是 db query 量跟频宽，说不定就真的需要这麽长 05/21 10:36
22F：→ chang505: 时间传输 05/21 10:36
23F：→ kojj: 就看Antonio 他检查完，能提供多少讯息。 05/21 16:02
24F：推 xxoo1122: 确认网卡跟网路设备的MTU 05/21 23:31
25F：推 torosome: 光纤多模距离太长会衰减 建议长距离都用单模光纤 05/24 22:05
26F：→ JamesGO: Traceroute或到各SW上ping server，先看延迟是不是真的 05/28 09:36
27F：→ JamesGO: 发生在网路上 05/28 09:36
28F：→ antonio9033: 感谢各位大大提供的建议，前几天在忙其他专案， 06/06 09:41
29F：→ antonio9033: 这周开始会继续各位提供调查方向，感温 06/06 09:41
30F：→ antonio9033: 有没有解决都会来回报检查结果 (_"_) 06/06 09:42
31F：→ antonio9033: 20220805-已与厂商讨论其会检查SQL端，目前尚未解决 08/05 14:09
32F：→ asdfghjklasd: 这不是很简单的问题吗???? 08/06 10:46
33F：→ antonio9033: 非常感谢各位大大拨冗分享，初步用iperf3实测结果-> 11/24 15:56
35F：→ antonio9033: 结果看来传输速度有落差。 11/24 15:58
36F：→ antonio9033: 近期请厂商来现场检测评估，初判是线路关系导致， 11/24 15:58
37F：→ antonio9033: 推测由於早期的光纤配线盘接点老化，导致端点不通， 11/24 16:02
38F：→ antonio9033: 才会以Cat.6跨栋牵线的方式替代，可能因距离导致衰弱 11/24 16:04
39F：→ antonio9033: 。接下来就是再安排整体线路改善计画，应能改善。 11/24 16:05