Od Servlet 3.0 asynchronous processing jest obsługiwany. Czy byłoby lepiej, aby zawsze używać przetwarzania asynchronicznego? Lub w jakich przypadkach lepiej jest przetwarzać synchronicznie?Serwlety asynchroniczne vs. Serwlety synchroniczne
Wielką zaletą asynchronicznych serwletów jest HTTP push, w której serwer może wysłać informacje do klienta, gdy wybierze, a nie wtedy, gdy klient o to poprosi. Serwlety pre-asynchroniczne wymagałyby długotrwałych połączeń HTTP, z których każdy wiązał wątek serwera, co jest bardzo nieefektywne. Ten nowy model oddziela przetwarzanie po stronie serwera od obsługi połączenia.
Przetwarzanie asynchroniczne zostało wprowadzone w przypadkach, gdy nie ma potrzeby trzymania nici podczas całego cyklu przetwarzania żądania. Typowym przykładem takiego przypadku jest funkcjonalność podobna do comet.
Korzystanie z przetwarzania asynchronicznego we wszystkich przypadkach nie byłoby nic warte, ponieważ zwykle przetwarzanie wewnętrzne kończy wątek.
Czytanie artykułu, obsługa asynchronicznego przetwarzania w specyfikacji Servlet 3.0 ma bardzo specyficzny przypadek użycia - jest zaprojektowana do obsługi przypadku, w którym masz aplikację AJAX, która wysyła żądania, które wyzwalają potencjalnie długo działające procesy w tle.
Powodem, dla którego potrzebowaliśmy czegoś takiego, była reakcja na problem w modelu wątku na żądanie, który przydziela wątek za każdym razem, gdy klient żąda strony od serwera, zamiast przydzielania pojedynczego wątku dla klienta. cała sesja. Sprawdzało się to dobrze przed AJAX, gdy klienci zgłaszali żądania sporadycznie, ale korzyści zostały utracone, gdy aplikacje AJAX znacząco zwiększyły liczbę żądań, które klient wykonałby.
W szczególności, jeśli żądanie AJAX wyzwala coś potencjalnie spowalniającego lub blokującego, np. Operacja bazy danych, wróciliśmy tam, gdzie zaczęliśmy - wątki z tego wątku są potencjalnie bezczynne.
Obsługa przetwarzania asynchronicznego próbuje złagodzić tę sytuację, umieszczając żądania w scentralizowanej kolejce, tak aby wątki nie zawsze były zablokowane podczas oczekiwania na wyniki żądań, które mogły jeszcze nie zostać jeszcze przetworzone. Krótko mówiąc, staramy się uzyskać najwyższy zwrot z naszych nici przez cały czas - to jest zmniejszanie czasu, w którym są bezczynni (ale może służyć innym łączom).
Tak jak w przypadku każdego nowego rozwoju, nie jest to coś, co można wykorzystać jako narzędzie uniwersalne. Poszukaj odpowiedniego przypadku w swojej aplikacji, gdzie jest to właściwe.
+1 "Czytanie artykułu ..." – user359996
Właśnie przejrzałem połączony artykuł, jest to ulepszenie po stronie serwera, a nie asynchroniczne po stronie klienta.
Podsumowując artykuł:
co chcesz używać asynchroniczne serwletów w sytuacji, gdy masz obciążenia żądań pochodzących z (podobne do walnąć serwer z żądań AJAX) i nie chcesz, aby służyć jeden wątek na żądanie. TPR może być niebezpieczny w tym scenariuszu, gdy czas przetwarzania zajmuje trochę czasu, powodując wyczerpanie puli wątków.
Zadanie zostanie zablokowane w kolejce zadań, a wątek może zostać wycofany, dopóki zadanie nie zostanie zakończone, a odpowiedź zostanie ostatecznie zatwierdzona, gdy zasoby zostaną zwolnione, aby umożliwić jej ukończenie.
Bardzo fajne rzeczy.
Jego oparte na requrirement gdzie wszelkie szanse nitki uzyskać w stanie bezczynności w tej sytuacji u należy użyć Asynchronous Servlet inaczej nie beacause nie możemy zrobić tak wiele gwint
Jeśli aplet lub filtr osiąga potencjalnie blokowanie operacji podczas przetwarzania żądania, może przypisać operację do asynchronicznego kontekstu wykonania i natychmiast zwrócić wątek powiązany z żądaniem do kontenera bez generowania odpowiedzi. Operacja blokowania kończy się w kontekście wykonywania asynchronicznego w innym wątku, który może wygenerować odpowiedź lub wysłać żądanie do innego serwletu.
Aby umożliwić przetwarzania asynchronicznego na serwlet ustawić parametr asyncSupported true z adnotacją @WebServlet następująco:
@WebServlet (urlpatterns = { "/ asyncservlet"}, asyncSupported = prawda) klasy publicznej AsyncServlet extends HttpServlet {...}
Synchroniczny (klasyczny model aplikacji sieci Web) Żądanie synchroniczne blokuje klienta do zakończenia operacji, tzn. przeglądarka nie reaguje. W takim przypadku mechanizm skryptowy java przeglądarki jest zablokowany.
Asynchroniczny (AJAX Web-Application Model) Asynchroniczne żądanie nie blokuje klienta, tzn. Przeglądarka reaguje. W tym czasie użytkownik może również wykonywać inne operacje. W takim przypadku silnik skryptowy java przeglądarki nie jest blokowany.
w komunikacji synchronicznej oba są aktywne w tym samym czasie, gdy w asynchroniczny ma potrzeby aktywne w tym samym czasie, na przykład asynchroniczny odnosi się do wiadomości nie blokuje działania do nowej nici i prowadzenia wątku powiązane z pojemnikiem
Kontenery sieciowe w serwerach aplikacji zwykle używają wątku serwera na żądanie klienta. W warunkach dużego obciążenia pojemniki wymagają dużej liczby wątków, aby obsłużyć wszystkie żądania klientów. Ograniczenia skalowalności obejmują wyczerpanie pamięci lub wyczerpanie puli wątków kontenera. Aby utworzyć skalowalne aplikacje internetowe, należy się upewnić, że żadne wątki powiązane z żądaniem nie są przechowywane w trybie bezczynności, więc kontener może ich używać do przetwarzania nowych żądań.
Istnieją dwa scenariusze, w których wątek związany z żądaniem może siedzieć bezczynnie.
+1 dla jasnego podsumowania. – BalusC
Co się dzieje, gdy sprawdzasz dane ajaxowe po stronie serwera, a użytkownik przechodzi na inną stronę internetową? Więc teraz nie potrzebują już tych danych? Albo co się stanie, jeśli użytkownik odświeży stronę? Czy byłyby teraz dwie instancje po stronie serwera sprawdzające te dane od użytkownika? – gmustudent