我在我的網站搜索框中創建自動提示功能，每當用戶按下一個新鍵時，javascript調用服務器端的web服務以獲得10從數據庫最相關的關鍵字，並再次給予JavaScript，並且JavaScript填充搜索自動推薦列表。
我的功能不是太慢，但比較live.com或google.com做的非常慢，我測試了它們，真的覺得它們是從我的電腦獲取關鍵字，而不是從它們的服務器獲取。
他們如何非常快速地獲取關鍵字，並確定他們的關鍵字有百萬次？
有這樣一個着名的風格嗎？
也使用我的螢火蟲，我發現他們沒有調用網絡服務「可能是通過我不知道的方式調用」，但我在網絡標籤中發現一個新的獲取正在發生。如何創建自動提示，以獲得與谷歌搜索或實時搜索一樣快的關鍵字
不知道，你正在尋找，但肯定對live.com我得到的每一個字母的請求：
Firbug Net Console - AutoComplete http://www.doodle.co.uk/userfiles/image/LiveNetConsole.png
正如你所看到的，有很少跨線回來 - 500B - 這就是您要達到的目標 - 一種精益Web服務，它返回您需要顯示給用戶的最小值。
然後最重要的是，正如其他人所說，以前的緩存響應等
不，結果往往是不按字母順序排列，所以如果你不顯示您的排序標準，可以遵循「現在比以後完全準確」的原則。
我建議的第一件事就是確保你的web服務將關鍵字緩存在內存中，而不是每次都打到數據庫 - 當然假設你的數據集足夠小，可以做到這一點。
除此之外，您將不得不以多種方式在多個服務器上並行執行查詢，這可能比您想要的要複雜得多。
首先，你應該重新說出你的問題。任何回答「我怎麼能和谷歌一樣快」肯定會是「習慣失望」。
鑑於此，您仍然可以使您的解決方案更好。似乎每次按鍵時，您都會前往服務和數據庫。我懷疑谷歌正在那樣做。也許你應該專注於做更少的往返行程（cahcing，當你必須去DB時帶回更多，等等）。
而不是每個按鍵都發出一個請求，如果您只是在每個特定時間段發出請求（如果在此期間有按鍵），該怎麼辦？如果你做了100毫秒的間隔，它仍然看起來是「即時」的，但可能會減少服務器上的負載。另外，你有客戶端緩存的關鍵字？如果用戶在搜索字段中退格，則不必重新聯繫服務器以獲取關鍵字。此外，您可以在每次按鍵時立即過濾當前關鍵字列表，而無需與服務器聯繫（由於部分/全部已包含的字母不會包含剛輸入的字母，因此最終只有不到10個關鍵字）。這可以填補實際的數據請求之間的「空白」，以使其看起來更加即時。
你能解釋一下「每隔一段時間提出一個請求」的想法嗎？，接合一些聰明的東西，但我覺得我無法理解它的完美。 – 2009-04-21 21:11:11
沒有理由在每次按鍵時都要求搜索字詞。谷歌做到了（1），因爲他們可以，並且（2）因爲他們在互聯網語料庫中呈現術語。
在大多數Web應用程序中，「常見」搜索項的數量要少得多 - 通常不超過一百個左右，並且只有十幾個上下文恰當。
您可以檢索整套相關條款，並在頁面加載時在客戶端構建前綴映射。通過將當前搜索字詞與此前綴地圖進行匹配，您可以爲Google提供更快的建議。
限制是，在某些時候，您將用完建議的條款。但是，這確實不是問題：甚至谷歌對「跨國性」（一個虛構的詞，但有191個全面搜索的結果）的用戶提出了一些建議。
正如有人建議使用ETags與REST API可能意味着一些額外的緩存重複查詢。查閱關於Jeo Gregorio博客的this文章，瞭解更多信息在REST上下文中的etags。
有，你可以做兩兩件事：
發現這個博客帖子裏面在談細節了這一點：
1）他們有更多的帶寬。 2）他們有更多的服務器3）。當搜索並獲得整頁結果時，無論如何你都會得到這些結果，所以一個10的js列表很可能發生得更快。 – 2009-04-21 20:47:07