Jeden wątek na klienta. Wykonalny?

Question

Piszę serwer Java, który używa zwykłych gniazd do akceptowania połączeń od klientów. Używam dość prostego modelu, w którym każde połączenie ma własny wątek odczytywany z niego w trybie blokowania. pseudokod:

handshake(); 

while(!closed) { 
    length = readHeader(); // this usually blocks a few seconds 
    readMessage(length); 
} 

cleanup(); 

(Nici są tworzone z Executors.newCachedThreadPool() więc nie powinno być żadnych istotnych nakładów na ich rozpoczęciem)

Wiem, że to trochę naiwne konfiguracji i to naprawdę nie będzie skalować również do wielu połączeń, jeśli wątki były dedykowanymi wątkami systemu operacyjnego. Słyszałem jednak, że wiele wątków w Javie może współużytkować jeden wątek sprzętowy. Czy to prawda?

Wiedząc, że będę używać maszyny wirtualnej Hotspot w systemie Linux, na serwerze z 8 rdzeniami i 12 GB pamięci RAM, czy uważasz, że ta konfiguracja będzie działać dobrze dla tysięcy połączeń? Jeśli nie, jakie są alternatywy?

Answer 1

Możliwe jest skalowanie do tysięcy klientów. Ale ile jest następnych pytań tysięcy.

Typową alternatywą jest użycie selektorów i niezablokowanych we/wy znalezionych w pakiecie java.nio.

Ostatecznie pojawia się pytanie, czy warto skonfigurować serwer w konfiguracji klastrowej, równoważąc obciążenie na wielu fizycznych maszynach.

Answer 2

To będzie dobrze skalować do setek połączeń, a nie do tysięcy. Jedną z kwestii jest to, że wątek Java zajmuje również sporo stosu (na przykład 256 KB), a system operacyjny będzie miał problemy z planowaniem wszystkich wątków.

Spójrz na Java NIO lub framworks, które pomogą Ci zacząć robić złożoną rzeczy łatwiej (np Apache Mina)

Answer 3

mieć dobry osiągów przy obchodzeniu się z wielu gniazd zazwyczaj użyć select podejście, które jest jak Unix API obsługuje wielowątkowe aplikacje jednowątkowe, które wymagają wielu zasobów.

Można to zrobić za pomocą pakietu java.nio, który ma klasę Selector, która zasadniczo może przeglądać wszystkie otwarte gniazda i powiadamiać użytkownika o dostępności nowych danych.

Możesz zarejestrować wszystkie otwarte strumienie wewnątrz pojedynczego Selector, a następnie możesz obsłużyć wszystkie z jednego wątku.

Można uzyskać dodatkowe infos z samouczka here

Answer 4

wątki nie są tak drogie jak kiedyś, więc „zwykłym” realizacja IO może być ok do pewnego momentu. Jeśli jednak patrzysz na skalowanie do tysięcy lub więcej, prawdopodobnie warto zbadać coś bardziej wyrafinowanego.

Pakiet java.nio rozwiązuje ten problem przez zapewnienie IO multipleksowania/blokowania gniazd, co pozwala powiązać kilka połączeń z jednym selektorem. Jednak to rozwiązanie jest o wiele trudniejsze w porównaniu z prostym podejściem blokującym ze względu na wielowątkowość i brak blokowania.

Jeśli chcesz realizować coś poza prostą operacją IO, sugerowałbym przeglądanie jednej z dobrej jakości bibliotek abstrakcji sieci. Z osobistego doświadczenia mogę polecić Netty, który wykonuje większość kłopotliwych operacji NIO.Ma jednak trochę krzywej uczenia się, ale kiedy już przyzwyczaisz się do podejścia opartego na zdarzeniach, jest bardzo potężny.

Answer 5

Jeśli interesuje Cię wykorzystanie wdrożenia i zarządzania istniejącym kontenerem, możesz rozważyć utworzenie nowej procedury obsługi protokołów w Tomcat. Zobacz this answer na pokrewne pytanie.

UPDATE: This post Matthew Schmidt utrzymuje złącze Nio oparte (napisany przez Filip Hanik) w Tomcatem 6 osiągnięty 16000 jednoczesnych połączeń.

Jeśli chcesz napisać własne złącze, spójrz na MINA, aby pomóc w abstrakcjach NIO. MINA ma również funkcje zarządzania, które mogą wyeliminować potrzebę użycia innego kontenera (w przypadku wątpliwości dotyczących rozmieszczenia wielu jednostek i ich działania itd.).

Answer 6

Urządzenie JVM dla Linux wykorzystuje odwzorowanie pojedynczych nitek. Oznacza to, że każdy wątek Java jest mapowany na jeden natywny wątek systemu operacyjnego.

Więc tworząc tysiąc lub więcej wątków nie jest dobrym pomysłem, ponieważ będzie to wpływać na wydajność (context switching, cache wypłukuje/misses, synchronization opóźnienia itd.) Nie ma to sensu, jeśli masz mniej niż tysiąc procesorów.

Jedynym odpowiednim rozwiązaniem dla obsługi wielu klientów równolegle jest użycie asynchronicznych operacji we/wy. Szczegółowe informacje można znaleźć na stronie this answer pod adresem Java NIO.

Zobacz także:

• Green threads
• Solaris threading models

Answer 7

Spróbuj Netty.

Model "jeden wątek na żądanie" jest sposobem zapisywania większości serwerów aplikacji Java. Twoja implementacja może być skalowana tak samo, jak robi.

Answer 8

Uważam, że lepszym podejściem jest nie radzić sobie z wątkami. Stwórz pulę (ThreadExecutor lub kilka innych rzeczy) i proste wysyłanie do puli.

Oczywiście, myślę, że asynchroniczne operacje we/wy sprawią, że będzie on lepszy i szybszy, ale pomoże rozwiązać problemy z gniazdem i siecią. Tylko. Gdy twoje wątki blokują się z powodu operacji we/wy, maszyna JVM uśpi ją i zmieni dla innego wątku, aż do momentu powrotu blokujących operacji we/wy. Ale to zablokuje tylko wątek. Twój procesor będzie działał i zacznie przetwarzać inny wątek. Więc, pomijając czas tworzenia wątku, sposób, w jaki używasz operacji we/wy, nie wpływa zbytnio na twój model. Jeśli nie utworzysz wątków (przy użyciu puli), Twój problem zostanie rozwiązany.

Answer 9

Zasugeruję, że zależy to bardziej od tego, co jeszcze robi serwer podczas przetwarzania wiadomości. Jeśli jest stosunkowo lekki, specyfikacja maszyn powinna ŁATWA poradzić sobie jedynie z obsługą połączeń tysięcy takich procesów. Dziesiątki tysięcy to może inne pytanie, ale potrzebujesz tylko dwóch maszyn w tej samej sieci, aby empirycznie je przetestować i uzyskać konkretną odpowiedź.

Answer 10

Po co wykonywać własne? Można użyć kontenera serwletów z serwletami, kolejką komunikatów lub ZeroMQ.