使用HttpHandler在ASP.Net網頁中加載縮略圖

Question

我的要求是在2秒內在Asp.Net Web應用程序中加載100張縮略圖。 每個圖像的實際大小約為800 KB。 因此，我使用了一個Web處理程序方法來即時調整圖像大小（此處圖像大小減小為8KB）。 在這里，我發現96個請求被發送到服務器，並且縮略圖在4秒內被加載。 我發現90％的時間都在Firebug的“網絡”標簽中檢查的阻止中丟失了。 因此，我從96個請求移至單個請求。 因此，Web處理程序接受單個請求並創建96個縮略圖圖像，然后將96個縮略圖組合成一個大的單個圖像並將該單個圖像寫入輸出流中。這種情況下，我發現加載單個圖像花費了大約6秒的時間。 然后我使用.Net線程池機制在Web處理程序中創建縮略圖，因此加載時間減少到2.6秒，發現服務器處理實際上只花費了1秒或更少的時間，而剩下的1.6秒正在丟失。 我的問題如下

1. 哪里浪費了我的處理時間。 服務器端還是客戶端？ 如果在服務器端，瓶頸在哪里？ 如何確定請求處理和頁面加載時間？

2. Web處理程序是調整圖像大小的更好方法嗎？

3. 我可以有其他替代解決方案嗎？

我的系統配置是

處理器-Intel Core-i7，RAM：-4 GB

Web服務器：IIS 7

作業系統：Windows 7

請幫我

Answer 1

>在哪里浪費我的處理時間。 服務器端還是客戶端？

也許介於兩者之間...傳輸數據的正確時間為1.6秒：

8KB per image * 100 images ~= 1MB of data
1 M bytes = 8 M bits
8 M bits / 1.6 secs = 5 Mbps transfer rate
... sounds reasonable to within an order of magnitude

您的單映像方法可能更好，因為這將減少100個單獨請求的開銷。 但是，請注意在ASP.NET進程中使用后台線程。

傳輸時間是一個限制因素。 即使您可以使服務器立即做出響應，您仍然必須等待數據返回到客戶端。

另一個限制因素是客戶端瀏覽器可以渲染圖像的速度。

基本上，您的要求正在突破實際ATM的界限。