Serwery www do tworzenia aplikacji:
- Node.js (JavaScript) - najpopularniejsza i najszybciej rozwijająca się technologia; wykorzystuje tylko jeden proces; oparty na wydajnej (jak na JavaScript) implementacji silnika JavaScript o nazwie V8.
- G-WAN web server (C, C++, Objective-C) - ultra-wydajny; wykorzystuje tyle procesów ile rdzeni/procesorów; dla zaawansowanych programistów (kod serwletów uruchamiany wewnątrz procesu co sprawia, że trzeba uważać na bezpieczeństwo).
- Jetty (Java, dowolny inny język na JVM) - standardowo od wesji 3.0 JavaServlet; można też użyć kontynuacji (cecha charakterystyczna dla tego serwera niebędąca częścią specyfikacji JavaServlet)
- Tomcat 7+ (Java, dowolny inny język na JVM) - podobnie jak w przypadku Jetty trzeba tworzyć aplikację w oparciu o JavaServlet 3.0
- JBoss Web server (Java, dowolny inny język na JVM) - j/w; bazuje na Netty (patrz niżej)
Narzędzia do tworzenia własnych serwerów (oraz klientów):
- epoll (C, C++) - niskopoziomowe API dla Linuxa do nasłuchiwania zdarzeń we-wy; czyli pozwala na monitorowanie wielu deskryptorów plików, w celu dowiedzenia się czy są gotowe na I/O (czyli czy na przykład można czytać z gniazdka); najwydajniejsze API jeśli liczba nasłuchiwanych plików liczona jest w tysiącach
- Node.js (JavaScript) - możliwość tworzenia serwerów/klientów TCP oraz UDP w uproszczony sposób w JavaScript;
- NIO i NIO.2 (Java) - najbardziej "niskopoziomowe" API w Javie; wykorzystuje m.in. epoll (implementacja maszyny na Linuxa)
- Netty, Apache Mina (Java) - warstwy abstrakcji nad NIO; systematyzują proces tworzenia asynchronicznych serwerów i klientów ułatwiając późniejsze utrzymanie kodu
Inne serwery www wykorzystujące nieblokujące I/O:
- Nginx - buforowanie wczytanych wcześniej plików w celu zwiększenia przepustowości spoczywa na systemie operacyjnym; reverse proxy; można wykorzystać do load balancingu oraz buforowania odpowiedzi serwerów (odpowiedzi są zapisywane na dysku); pozwala na pisanie modułów uruchamianych wewnątrz procesu (podobnie jak w G-WAN to dość niebezpieczne ale najbardziej wydajne)
- Varnish Cache - reverse proxy buforujący odpowiedzi serwerów; alokuje pamięć bezpośrednio (co zapewnia większą kontrolę niż w przypadku bufora systemu plików jak w przypadku Nginx); może służyć jako load balancer
Jak widać lista technologii jest mocno skrócona - opisałem tylko te, które znam i są gotowe do użycia na produkcji. Jeśli znasz jakieś inne narzędzia zapraszam do dodania komentarza, a ja uzupełnię wtedy wpis. Myślę, że na tym poście zakończę cykl traktujący o asynchronicznych serwerach sterowanych zdarzeniami. Jeśli jednak interesuje Cię ten temat i chciał(a)byś dowiedzieć się więc to zachęcam do dodania komentarza pod postem :)
Fajny cykl. Szkoda, że ansynchroniczne interfejsy do baz danych nie są jeszcze gotowe.
OdpowiedzUsuńProponuję jakiś kursik / wstęp do JavaServlet 3.0 jako kontynuację tematu.
Dzięki :) Dobry pomysł z tym tutorialem do JavaServlet 3.0. Wymyślę jakiś ciekawy przykład z użyciem asynchronicznego przetwarzania i opiszę w następnym poście.
OdpowiedzUsuńCzy interesowałeś się już może Erlangiem? Bardzo ciekawie i dogłębnie analizujesz temat serwerów nieblokujących, więc chętnie bym się dowiedział co sądzisz o języku programowania zaprojektowanym między innymi w celu pisania właśnie tego typu serwerów.
OdpowiedzUsuńNiestety do tej pory nie miałem okazji używać Erlanga. Wiem tyle, że Erlang wykorzystuje model aktorów zamiast wątków wspóldzielących ze sobą stan. Aktorzy nie współdzielą stanu (a wiadomości przekazywane między aktorami są niezmienne), więc nie ma potrzeby synchronizacji dostępu do danych za pomocą blokad. W konsekwencji być może łatwiej jest tworzyć programy mocno wykorzystujące procesory wielordzeniowe (a nawet wiele maszyn jednocześnie). Szczególnie przydatne gdy chcemy przyspieszyć jakiś długo wykonujący się algorytm wykorzystujący np. algorytm dziel i rządź. Co do wydajności aktorów - nie sądzę by można było wiele zyskać w porównaniu do "klasycznych" wątków (no chyba, że naprawdę w naszym kodzie co chwila są jakieś synchronizacje). Nie można jednak zapominać, że do skrzynek wiadomości każdego aktora może pisać wielu aktorów jednocześnie, więc i tak jakaś tam synchronizacja występuje. Niemniej w przypadku Erlanga jest to wbudowane w język więc można się spodziewać, że implementacja jest wysoce zoptymalizowana.
OdpowiedzUsuń