Akceptowanie puli i równoważenie obciążenia w Erlang?

Question

Od http://www.erlang.org/doc/man/gen_tcp.html#accept-1:

Warto zauważyć, że akceptuje połączenia nie muszą być wydawane z procesu właściciel gniazdo. Korzystając z wersji 5.5.3 i wyższej emulatora , można wygenerować wiele równoczesnych wywołań akceptowanych z różnych procesów, co pozwala puli procesów akceptorowych obsługi połączeń przychodzących.

(Q1) Czy to znaczy, że możemy mieć Unicorn -Style równoważenie obciążenia w Erlang?

(Q2) Jeśli tak, czy istnieją jakieś serwery lub biblioteki korzystające z tej funkcji?

(Q3) Unicorn działa przy założeniu, że żądania przetwarzania szybko. Czy przy takim samym założeniu możliwe jest uzyskanie lepszych wyników dzięki połączeniu akceptantów i pracowników w Erlang?

Dla tych, którzy nie znają Unicorn, jest to tradycyjny serwer internetowy z prefekturą UNIX. Równoważenie obciążenia między procesami roboczymi odbywa się w jądrze systemu operacyjnego. Wszyscy pracownicy dzielą wspólny zestaw gniazd nasłuchiwania i nie akceptują ich akceptacji(). Jądro zdecyduje, który proces roboczy daje gniazdo, a pracownicy będą spać, jeśli nie ma nic do zaakceptowania(). Dla pojedynczego gniazda nasłuchującego, uważam, że jest tak samo, gdy procesy robocze blokują accept(), a jądro systemu operacyjnego decyduje o wyniku "wyścigu".

Answer 1

Też wysłałem to pytanie w liście dyskusyjnej Erlanga. Jak podkreślił Daniel Goertzen, istnieją biblioteki basen akceptora w Erlang, takie jak ranch i swarm.

• ranczo działa odmiennie od Unicorn w taki sposób, że nie tylko „przyjąć” w wielu procesach, a następnie przechodzi przez gniazdo do pewnego procesu roboczego.

• Sposób rój działa jest taka sama jak Unicorn w tym sensie, że akceptor i pracownik łączy. (Dzięki Loïc Hoguin za wskazanie) Ale są nieco inaczej, ponieważ rój może zaakceptować nowe gniazdo w równolegle z przetwarzaniem przyjętego gniazda, natomiast Unicorn akceptuje tylko po akceptowane gniazdo jest przetwarzany

Preferuję styl roju, ponieważ jest idealny zarówno do szybkich, jak i powolnych zgłoszeń, podczas gdy Unicorn wymaga szybkich żądań.

Zamiast próbuje być skuteczne w służbie powolnych klientów, jednorożec opiera się na proxy odwrotnej buforowania aby skutecznie radzić sobie z powolnych klientów.

Jednorożec nie nadaje się do wszystkich zastosowań. jednorożec jest zoptymalizowany pod kątem aplikacji , które intensywnie wykorzystują procesor/pamięć/dysk i poświęcają niewiele czasu na oczekiwanie na zasoby zewnętrzne (np. serwer bazy danych lub zewnętrzny interfejs API ).

Jednorożec jest wysoce nieefektywny w aplikacjach Comet/reverse-HTTP/push , w których połączenie HTTP spędza dużo czasu bezczynnie.