2010-06-29 110 views
27

我需要一個二維數組(作爲Json)從服務器發送到客戶端。它的大小約爲400x400,每個條目大約有4個字符的文字。所以這使得它大約有640KB的數據。非常大的HTTP請求vs很多小請求

以下哪種極端方法更好?

  1. 我一次性發出大量的HTTP請求。
  2. 我做400個請求 - 每一個要求單排(約1.6 KB)

我相信最佳的做法是在中間的某個地方。任何人都可以給我一個想法什麼可能是這個數據的最佳單一請求大小?

謝謝。

回答

37

除非你正在處理慢(很慢按照今天的標準)連接,真正需要增量更新,這樣做在一個請求。

這樣可以爲您提供更好的效率compressing the response,並避免了extra HTTP requests and response headers的開銷。

+3

+1 - 你可以避免往返的開銷。即使在20ms ... 400個請求會使8000ms開銷= 8秒。在80ms ......(很遠)的時候,這將浪費32秒。 – TomTom 2010-06-29 06:42:22

+0

非常感謝David&Tom。這真的很有用。 :) – 2010-06-29 07:54:52

+2

那麼,@TomTom你沒有考慮並行請求...!如果沒有併發連接限制,則它在開始和結束時只有20ms的完美連接:)糾正我,如果我錯了,它只有400 x(處理標頭的時間量)而不是400 x RTT – 2017-01-18 11:30:56

47

夫婦考慮選購一大VS幾個小:

  • 在單個請求的情況下,作爲數據到達你不能做漸進式的數據處理;你需要等待完整的數據包到達之後才能做任何事情。如果失敗了,你需要從頭開始一切。
  • 在多個請求的情況下,您可以執行漸進式數據處理。但是,您現在必須考慮多重故障的可能性以及如何從這些故障中恢復。
  • 多個請求會導致每個請求的開銷。這是您應用程序將消耗的額外帶寬。
  • 某些HTTP代理限制了對同一服務器的併發請求數,並且您可能需要執行一些邏輯來解決該問題。
  • 對於單個請求情況,響應壓縮將更好地工作。
  • 多個請求不會要求您爲數據分配完整內存。當然,640KB並不是那麼大的內存,所以這可能不是你的重要考慮因素,這取決於你分配它的頻率。
  • 如果提前終止進程(取消按鈕或應用程序終止或瀏覽器導航離開您的頁面),單個請求仍將完成完整的響應下載;但是,對於多個請求的情況,您的代碼尚未開始的任何請求都不會執行。

老實說,我不會擔心最後兩個,並會根據我的選擇1)是漸進式數據處理的重要;和2)你的應用程序容錯是什麼對於失敗和部分數據。

+7

+1我覺得這個答案比目前接受的答案要好得多,因爲它提供了兩種選擇的比較,而不是直接的答案。 – Wingblade 2013-05-18 18:19:48