2011-09-24 159 views
0

我寫的關於如何組織是在一個HTTP請求發送的查詢參數的規範,我想出了以下內容:請求大小VS服務器負載

所有參數與實體前綴,以他們屬於一個例子「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,但是這給服務器增加了額外的負擔,因爲它必須解析字符串才能處理這些值。

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

回答

0

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

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

0

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