作者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/m.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