請求大小VS服務器負載

Question

我寫的關於如何組織是在一個HTTP請求發送的查詢參數的規範，我想出了以下內容：

所有參數與實體前綴，以他們屬於一個例子「ab」，它被讀作「實體a的b」，這樣每個參數將被清楚地映射到相應的實體，但是如果存在共享查詢參數的兩個不同實體呢？以避免重複和請求大小我想出了以下微格式。要有一個名爲shared的請求範圍實體，shared的每個屬性將表示在實體間共享的屬性，例如，

 

POST /app/my/resource HTTP/1.1 
a.p = v 
b.p = v 
c.p = v 
d.p = v 
 

這清楚地表明財產p是其中a,b,c共享和d所以這可能是因爲

POST /app/my/resource HTTP/1.1 
shared.p = a:b:c:d%v 

現在發送，請求比較小，我是有點更DRY，但是這給服務器增加了額外的負擔，因爲它必須解析字符串才能處理這些值。

也許在我的例子中，差異是微不足道的，我可以選擇，但我想知道你對它有什麼看法，你喜歡什麼，也許請求的大小無關緊要，或者可能是當長度很短時，解析字符串並不是什麼大問題，但是當我們擴大請求和字符串的大小時會發生什麼，哪一個更好，什麼是折衷？

Answer 1

你所顯示的是一種壓縮算法。請注意，有效載荷通常在協議層上已被壓縮（HTTP，gzip Content-Type，請參閱HTTP compression examples）。壓縮算法足夠先進，可以壓縮重複的字符串項目，所以可能你不會通過自定義壓縮獲得太多的收益。

一般儘量不要過早優化。首先顯示您正在處理響應時間或有效負載大小問題，然後進行優化。你的壓縮算法本身是一個好主意，但它使得有效載荷比普通的鍵/值對（xxx-form-urlencoded Content-Type）更復雜。出於維護的原因，儘可能採用最簡單的設計。

Answer 2

只是爲了拋出這個問題，我認爲答案取決於您的後端服務器運行哪個平臺來處理請求。例如，我最後一次檢查時，基於Perl的mod_perl可以更快地解析這些字符串，比如ASP.NET。