Web Test 的測試中有一個檔案404，是否可以當個案？
問題
首先我們還是先看一下圖片，有一個 Request 頁面發生錯誤。
原因是某一個圖檔 404 的關係 ( 無法下載該檔案 ) ，而 A 公司的朋友就有疑問
「在操作的時候都很正常沒有發生錯誤，那這個問題應該可以當個案吧？」
不知大家看到這個問題會不會覺得很嚴重？？
一、不會，反正功能可以動。
二、應該有影響，但先放著應該沒有什麼太大的關係。
三、會，應該立即修正問題。
大家會選那一個？？
↓
↓
↓
↓
↓
↓
↓
↓
問題很嚴重
通常大家看到這樣子的錯誤，其實都會認為無所謂。
只要不是破圖、客戶沒有發現就先放著吧！反正程式可以正常跑！
再說時間只有 0.068 而已，這應該不會有效能衝擊的影響
其實，剛好在 2 個月前我幫 C 公司做壓力測試時也遇到一樣的問題
千萬請不要輕乎它，這會讓系統的 Request Queue 問題持續擴大
(註： Request Queue 代表有多少的使用者正在排隊等待伺服器的回應 )
雖然 現在看到 時間只佔 0.068 ， 若是 1000 人的話就會佔用掉 68 秒以上的運算時間。 ( 不包含排擠效應 )
明明系統可以服務 1200 個使用者，但卻因為 404 的關係而少服務了 200 個使用者，或是 每個使用者要多花 0.5 秒的時間等待。
原因
我們在網頁最佳化時，其中可以改善的項目之一就是 Request 最佳化
基本是透過 js 、CSS 可以壓縮成一個檔案做批次下載，圖檔也會結合成一個大圖檔
( 有興趣的朋友可以透過 NuGet 下載 Framework 來用 )
因為一個 Client 對一台 Server 時同時能下載的檔案數就是 2 個，若超過 2 個的話就要等待下次的 Request
這樣子網路一來一往自然就快不起來，畢竟 Web 系統中網路畢竟是最不可靠最慢的項目之一。
ex.. 每一個檔案平均都是 0.05 的 Request Time，假使有 100 個檔案要下載，並以 2 個下載項目並行。至少就要花費 2.5 秒在 Request Time 上
早期為了解決這個問題，是統一將檔案分散在各個不同的 Server ，以超過 2 個下載的限制，但卻額外造成部署和管理的困擾
回到原本的議題
即然同一個時間只能同時 2 個檔案下載，那其中有 404 的檔案自然就會排擠到其他檔案
若 404 檔案是真的沒有用到的檔案，那我們不就白白等了？
這種隱性的效能衝擊通常都是比較不易查覺的，即然我們用 Web Test 做分析 那麼就不要視而不見
當然，效能問題並不是紙上談兵就了事的
還是要真槍實彈地用 Visual Studio 工作進行 Load Test 才能真正釐清問題
畢竟影響效能的原因是百百種…
