2010-08-01 140 views
3

我想知道是否有性能(或其他重要的因素),通過這種方法從我們的服務器發送到瀏覽器中的文件之間的差異:發送二進制數據流客戶端瀏覽器

For i = 1 To fileSize \ chunk 
    If Not Response.IsClientConnected Then Exit For 
    Response.BinaryWrite stream.Read(chunk) 
    Response.Flush 
Next 

VS

IIS自帶的舊純文件訪問方法。

出於安全原因,我們正在研究文件管理器處理程序,並希望知道性能影響是什麼。

+0

您發送的內容類型是什麼,典型的大小範圍是多少,您可能期望的併發下載次數,頻率如何。 – AnthonyWJones 2010-08-03 09:21:50

回答

2

除非你正在處理一個相當大的文件,不應該有一個明顯的區別。由於您正在手動創建塊並刷新緩衝區,因此您將擁有更多的數據包流量到客戶端(數據包的有效負載或最後一個數據包將只部分滿)。但是,正如我所說的,除非你有一個大文件,否則這個文件可能不會被注意到,即使它不可能出現。

+0

我上次測試這個'Flush'會阻塞,直到收到刷新的數據包的所有ACK。所涉及的延遲會導致更長的下載時間,您可能會想到。它有可能IIS7可能已經改變了這種行爲。使用較大的緩衝區大小(如64K)可以最大限度地減少此延遲的影響和發送的額外數據包的數量。 – AnthonyWJones 2010-08-02 12:21:11

+0

我很努力不以「這取決於」的答案:) 有在IIS 5 + 6之間做出了一些改變,但也有一些額外的因素:你計算性能作爲運行服務器端腳本的性能,從請求到交付的總時間,服務器上的資源負載?雖然會發生阻塞,但數量取決於您正在刷新的數據量(正如您在下面指出的那樣),整個事情將取決於文件的大小(在這一點上,您必須平衡服務器上的內存使用情況並防止出現阻塞/ network latency/under-sizing packets)等。 – Tarwn 2010-08-02 14:01:29

+0

謝謝,我們將運行一些測試,看看網絡過載如何分割塊。 – AMember 2010-08-03 08:01:59

2

這兩種方法都需要將二進制數據推送到瀏覽器。

想知道什麼是對性能的影響。

像往常一樣在這樣的情況:指標。嘗試優化IIS上的設置並再次測量,直到獲得最佳解決方案。

+0

在這種情況下,IIS中的哪些設置可以進行優化以獲得最佳性能? – AnthonyWJones 2010-08-02 12:22:23

0

根據我的經驗,使用腳本來分塊的東西明顯比IIS高度優化的靜態文件處理慢。當其他糟糕的選擇已經完成時(比如使用4096個字節作爲緩衝區大小),速度慢多少取決於我見過的多達10倍的因素。

有些東西可能已經IIS7改善,但如果你能獲取文件爲靜態內容,我肯定會與該走了。