基於URL長度的API的性能

目前在構建API的過程中，我想知道URL的長度是否對API的性能有任何影響？基於URL長度的API的性能

例如

具有K =代替API_KEY =在查詢字符串，或者限制實際API_KEY到X字符，而不是32個字符（MD5散列例如）。

請記住，這個API將用於4-5箇中等規模的網站

2011-05-04 Stoosh

你能解釋一下你的意思嗎？您是否在談論解析URL所花費的時間？ – Charles 2011-05-04 23:34:19

不重要。 – KingCrunch 2011-05-04 23:34:37

在服務器上加載實際請求的速度，但規模相當大 – Stoosh 2011-05-04 23:35:18

有K =代替API_KEY =在查詢字符串，或限制實際API_KEY到X字符，而不是32個字符（例如md5散列）。

速度差異會非常微小 - 六個字符與一個字符讀取 - 這是完全無關緊要的。

請記住，雖然URLs don't have an RFC-spec length limit，由於IE問題，保持它們低於2000個字符是一般的做法。將兩千個字符的查詢字符串轉換爲可行的參數是無關緊要的，無論您使用何種編程語言。

如果你是認真擔心URL解析的性能特點，我會打賭，你可能需要坐下來與一個代碼分析器，並找出你的性能指標實際上是，因爲你完全看錯了地方。

2011-05-04 23:40:23 Charles

這是非常棒的信息，非常感謝。從帶寬的角度來看呢？ – Stoosh 2011-05-04 23:54:43

@Stoosh，帶寬可能是一個小問題，但我期望實際的API參數 - 而不是API密鑰樣板等 - 是一個更大的問題......並且完整的HTTP頭文件是一個更大的問題。它會加起來。（這種說法通常是關於具有較大價值的餅乾。） – Charles 2011-05-05 00:08:37

非常感謝您清理那些 – Stoosh 2011-05-05 00:13:35

它不會在服務器負載或速度上算很多，但可能在帶寬上。 URL是發送到和接收API的HTTP消息的一部分，如果有很多，那麼每個字節都會被計算出來，因爲差異會被每個HTTP消息乘以。

但是queryinfo部分的大小隻是它的一個非常小的方面 - 但是，它可能在你正在做的事情中扮演一個角色 - 我不能真正說出:)例如，如果帶寬是瓶頸，那麼你的優化想法可能會有所幫助（一點點）。

2011-05-04 23:42:16 hakre

這將從來沒有是你的瓶頸。

根本不用擔心。

2011-05-04 23:46:04

回答