AJAX的適用範圍以及對伺服器的效能影響

 

AJAX熱了也有兩三年了，它對WEB帶來革命性的改變以及對為使用者帶來的前所未有的體驗感受是毋庸置疑的。雖然AJAX會給WEB應用程式帶來很多好處，但是在AJAX應用用在什麼地方，怎麼用仍然需要認真考慮，千萬不可以濫用。

首先闡述幾個老問題：

第一個老問題，由於AJAX需要javascrip的支援，另外還需要用到xmlhttp對象，所以對於瀏覽器的相容性需要考慮。可喜的是，市面上 決大多數的瀏覽器都已經支援xmlhttp以及javascript。到目前，我們幾乎可以最小程度的考慮相容問題，但並不代表可以忽略它，畢竟不同的瀏 覽器執行相同用戶端代碼會產生不同的效果。

第二，使用者的習慣性，很多使用者習慣與使用傳統的方式來與伺服器進行互動，雖然他們也許已經厭倦，但是習慣就是習慣，突然出現一種新的方式的時候反而 會讓他們不知所錯。AJAX不需要重新整理瀏覽器，因此在很多情況下使用者執行一個操作後發現瀏覽器並沒什麼動靜會感到很迷茫，特別是當網路速度慢的時候，使用者 的一個請求需要很長時間才能反應，在等待的這段期間，使用者也許會認為WEB有問題關掉瀏覽器或則再做別的什麼事情。另外，使用者會習慣於瀏覽器提供的一些功 能，比如前進、後退、重新整理、停止，這些功能是使用者會經常並習慣用到的，當採用AJAX的時候會導致這些功能多失效，當然現在有很多人都寫出瞭解決的方法， 網上有很多這些解決方案的文章。

另外還需要注意的一個問題是對伺服器的效能的影響。

AJAX非同步請求，這個方式會帶來一個新問題。傳統方式中，對於一個使用者而言使用者每對伺服器進行一次請求需要等待伺服器做出響應後才能對伺服器進行 另一次請求，這樣後面的請求能確保是在上一個請求執行完以後處理的。但是AJAX打破了這種束縛，一個使用者就可以快速的連續的執行多次請求，相對於傳統方 式來說，這會對伺服器提出更高的要求以及對程式設計者帶來更大的挑戰。通常情況下，應該盡量避免這種情況，例如sina的評論頁，分頁的拖動條採用的就是 非同步請求的方式，使用者拖動遊標可以很方便的定向到需要的分頁，但是在拖動的過程中，遊標每到一個分頁點都會向伺服器請求相應的資料，如果使用者以一個特定的 速度將遊標拖動到第10頁，那麼伺服器將會有9次的請求是多餘的，如果這9次多餘的請求都讓伺服器執行了讀取資料庫的工作，那麼這將會浪費大量的伺服器資 源。如果使用者發現第10頁沒有他想要的東西，於是又移動到第9頁，伺服器又將請求相應的資料，但是實際上伺服器在曾經擷取過同樣的資料，如果這樣的事發生 在現實的生活中也許你就會覺得這樣真的很多餘很浪費。

OK ，還是以分頁為例，如果我們不用拖動條，按照以前的分頁思路“所得及所需”，每次請求不同的頁只擷取該頁的資料，並使用AJAX給使用者更好的體驗感受。這 樣好象就合理了，因為以前大家都這麼做，但是實際上並不是最合理的方法。通常情況下，使用者最喜歡看的是前3頁，這3頁被反覆請求的可能性是最大的。在傳統 模式中， 由於不管怎麼樣都會回送伺服器處理，所以在分頁思路上提出了“所得及所需”的說法。但是如果在使用AJAX的時候還用這樣的思路就稍顯死板。既然都使用了 AJAX那麼很能確定的是你的使用者需要支援javascript，那麼何不在用戶端再分頁呢？前面說到，使用者最喜歡的前3頁，假如，使用者需要從第1頁讀到 第3頁，如果是“所得及所需”，那麼不管用沒用AJAX，使用者在讀到第3頁的這個過程中都需要請求3次伺服器。

我們來比較一下這兩種情況（假設沒頁10條資料）：

1、產生3次請求+開啟3次資料庫+每次讀取並傳送10條資料的資料量
2、產生1次請求+開啟1次資料庫+每次讀取30條資料並傳送

情況2比情況1少開啟2次資料庫，上執行2次資料庫查詢，少2次請求，多20行的查詢資料量

很明顯，在這個過程中第2中情況下，使用者將會等待更少的時間，並且伺服器也會做更少的處理。

這就是我所提出的新的分頁方式，一次性讀取出使用者將會多次請求的資料，然後在用戶端進行分頁。使用者在第一次請求的時候獲得更多的資料，然後在通過客 戶端處理，這樣在使用者從第1頁讀到第3頁的這個過程中不需要再請求伺服器，前3頁的切換會變得更方便，也會減輕伺服器的負擔。唯一的壞處很明顯是使用者第一 次請求會等待稍微長一點，但是多20條資料的查詢量和傳送量比起頁面切換所節約的時間來說是微不足道的，另外別忘了AJAX，利用它我們可以讓使用者感覺不 到這多的20條資料的處理量。

利用AJAX可以為使用者帶來很好的使用者體驗，但處理的不好的話會導致伺服器承受更大的負擔，同樣處理得好的話，可以減輕伺服器多餘的負擔，具體情況就看怎麼用了。