Odpowiedzi:
To zależy od tego, co robisz i jak to robisz.
Jeśli zamieniasz pełne ładowanie strony na żądania AJAX (tzn. Wykonujesz wywołania AJAX tylko wtedy, gdy użytkownik kliknie to, co byłoby pełne ładowanie strony), AJAX zmniejszy obciążenie serwera, ponieważ (prawdopodobnie) robisz mniej przetwarzania i zwracasz mniej dane.
Z drugiej strony, jeśli dodajesz automatyczną aktualizację typu AJAX, która sonduje serwer co kilka sekund, może to zwiększyć obciążenie w zależności od użytkownika (może nie zwiększyć obciążenia serwera, jeśli użytkownik nadal naciska F5, aby odświeżyć ręcznie, ale większość ludzi na ogół nie robi tego przez wiele godzin)
Inną optymalizacją AJAX jest ładowanie większej ilości danych podczas przewijania. W takim przypadku, jeśli użytkownik nie przewinie do końca, marnuje się przetwarzanie.
Oczywiście w rzeczywistości implementacja może wypaczać wyniki w obu kierunkach, są to typowe wyniki przy założeniu dość dobrych implementacji.
Oczywiście służy to zmniejszeniu obciążenia serwera. Spójrz na tę prezentację @ jsconf'09 - jak Facebook użył do tego ajax.
Ajax jest asynchroniczny. komunikacja z serwerem - i możesz z niej korzystać na wiele sposobów. Ludzie używają go do ładowania prostego JSON-a do sieci w czasie rzeczywistym i wszystkiego pomiędzy.
Pamiętaj - prawdziwym wyzwaniem jest równowaga między klientem a serwerem. Staraj się, aby każda ze stron wykonywała swoje zadania w taki sposób, aby system był zoptymalizowany, a otrzymasz oczywiste korzyści z dostrzegalnego czasu reakcji i prawdziwej prędkości.
Są inne czynniki, których nie bierzesz pod uwagę - w większości przypadków AJAX zwiększy obciążenie serwera. W typowym scenariuszu innym niż ajax użytkownik ładuje jedną dużą stronę co kilka sekund lub kilku minut. Tak, ta pojedyncza strona to trochę więcej pracy dla serwera, ale ma dużo czasu między żądaniami do odzyskania i obsługi innych żądań. W scenariuszu AJAXified ładowanie pojedynczej strony jest teraz dziesiątkami małych trafień, ciągle wbijających serwer i czekających na odpowiedzi.
To trochę jak śmierć z 1000 cięć - żadna z tych próśb nie jest tak duża sama w sobie, ale całkowita waga jest zabójcza. Zwłaszcza, gdy zaczniesz rozważać, że te małe żądania są prawie tak samo drogie, aby służyć jako żądanie na całej stronie. W obu przypadkach prawdopodobnie biegniesz przez cały potok aplikacji WWW, trafiasz do bazy danych i czekasz na odpowiedź, siedząc na cennym połączeniu HTTP.
Oto przykład tego, jak ajax może naprawdę szybko stać się brzydki na serwerze. Weźmy typowy „pulpit wykonawczy”, który ma 4 miejsca na widżety. Powiedzmy, że CEO lubi pełny raport sprzedaży po prawej stronie, listę 10 najlepiej zarabiających po środku i raport cen akcji firmy po prawej stronie. Powiedzmy, że zrobimy to za pośrednictwem prostych, zdalnych żądań ajax. Bez uwzględnienia arkuszy stylów, obrazów i innych zasobów, twoja strona wymaga teraz 4 połączeń w obie strony HTTP (strona główna, każdy z raportów deski rozdzielczej) przeciwko serwerowi. Każdy z nich wymaga pełnego stosu internetowego do wykonania - będziesz uderzać w bazy danych i renderować HTML przy użyciu swojego frameworka, prawda? Teraz pomnóż jednego CEO przez 2000 zdalnych użytkowników, z których niektórzy mają nieregularne połączenia.
I odwrotnie, możesz mieć pojedynczą stronę po stronie serwera, która wykonuje i zwraca szkielet HTML, a także dane (zawarte w JSON na stronie) do renderowania raportów. Pojedyncze, większe połączenie, ale w sumie mniej bijące na serwerze internetowym, ponieważ nie obsługujesz 4 żądań i rozpędzasz 4 potoki itp.
Jeśli używasz AJAX do zastąpienia pracy, którą w innym przypadku wykonałby serwer, to tak, poprawi to wydajność serwera. Być może jednak zaprojektowałeś rzeczy tak, aby serwer nadal działał tak samo, a teraz wszystko, co dzieje się z AJAX, jest nadrzędne w stosunku do tego, co serwer już robił.
W większości dotyczy to interfejsu użytkownika, ponieważ nie powinieneś robić nic innego po stronie klienta. Zasadniczo wszystko, co serwer robił w celu obsługi interfejsu użytkownika (np. Przeładowanie strony z innym układem w odpowiedzi na dane wprowadzone przez użytkownika), robi za pomocą JavaScript.
Jeśli renderowanie HTML stanowi ogromną część profilu wydajności serwera aplikacji, wówczas przeniesienie renderowania HTML do klienta może przynieść poprawę wydajności na serwerze aplikacji.
Jeśli jednak renderowanie HTML stanowi niewielką część profilu wydajności serwera aplikacji, więcej żądań zwykle oznacza więcej podróży przez stos, więcej zapytań, więcej wszystkiego na serwerze aplikacji, utratę wydajności.
Oczywiście jedynym sposobem na poznanie w konkretnym przypadku jest wypróbowanie go.
Musisz rozważyć najlepszy sposób wdrożenia swojego rozwiązania. Prosta niedynamiczna forma nie wymaga ajax, a dodanie jej może faktycznie zaszkodzić wydajności. Jeśli twoim problemem są złe zapytania, cała optymalizacja ajax na świecie nie zapewni ci wzrostu wydajności, który będzie akceptowalny.
Jeśli twój serwer jest przepracowany, musisz dowiedzieć się, dlaczego.
Jeśli otrzymujesz dużo trafień, to ajax nie naprawi tego problemu, potrzebujesz większej pojemności. Dodanie ajax tylko zwiększy liczbę żądań, które serwer musi obsłużyć.
Jeśli masz skomplikowaną stronę, powinieneś sprawdzić, czy jest coś, co możesz zrobić po stronie klienta, aby zmniejszyć obciążenie serwera. Jeśli twoja strona jest dynamiczna, ale tak naprawdę ma ograniczony pakiet danych, buforowanie po stronie klienta może się lepiej opłacić.
A czasami Ajax pomoże. Gdy masz złożone formularze z danymi dynamicznymi, ajax wygrywa dzień. Ale jeśli twoje zapytania są skomplikowane i zajmują dużo czasu, to ajax wciąż nie rozwiąże twojego problemu.