Jak ciężcy są aktorzy akka?

Question

Jestem świadomy, że jest to bardzo nieprecyzyjne pytanie i może zostać uznane za nieodpowiednie dla stosu. Niestety, mniejsze aplikacje (pod względem liczby aktorów) i "podobne do tutorialu" nie pomagają mi rozwinąć intuicji na temat nadmiaru wiadomości i szybkiego określania granularności między "obiektem scala" a obiektem "corba" .

Podczas gdy niemal na pewno utrzymywanie stanu rozmowy z klientem na przykład zasługuje na aktora, w większości przypadków rzeczywistych wymagałoby to interakcji warunkowych/równoległych/alternatywnych modelowanych przez wiele klas. Pozostawia to wybór między traktowaniem aktorów jako elewacji do dość złożonych usług, podobnych do słusznie wycofanego EJB, lub podobnych do obiektów smalltalk, wysyłając komunikaty między sobą, chcąc nie chcąc, kiedykolwiek komunikacja może być zaimplementowana w sposób asynchroniczny.

Oprócz narzutów związanych z przekazywaniem wiadomości, nie będzie również obciążenie związane z zarządzaniem cyklem życia i jestem ostrożny z potencjalnymi problemami spowodowanymi przez łańcuchowe ponowne uruchamianie całych poddrzew aktorów z powodu wyjątków lub innych błędów w katalogu głównym.

Dla tego pytania możemy założyć, że znaczna większość komunikacji odbywa się w ramach jednej maszyny, a przecinanie sieci jest nieznaczne.

Answer 1

Nie jestem pewien, co masz na myśli, mówiąc o "napowietrznych wiadomościach przekazujących się". Gdy sieć/serializacja nie jest zaangażowana, obciążenie jest nieistotne: jedna strona przesyła komunikat w kolejce, a druga odczytuje go z kolejki.

Akka twierdzi, że może działać nawet 50 milionów wiadomości na sekundę na jednej maszynie. Oznacza to, że nie używałbyś aktorów jako fasad do złożonych podsystemów. Wolisz zamodelować je jako mniejsze "jednostki robocze". Mogą być bardziej złożone w porównaniu do małych obiektów, gdy są wygodne. Mógłbyś, na przykład, KafkaConsumerActor, który wykorzystałby wewnętrznie inne "normalne" klasy, takie jak Połączenia, Konfiguracja itp., Nie muszą to być akka aktorzy. Ale wciąż jest wystarczająco mały, aby być prostą jednostką roboczą wykonującą jedną prostą czynność (spożywając wiadomość i wysyłając ją gdzieś).
50 milionów sekund to naprawdę dużo.

Ślad pamięci jest również bardzo mały. Akka sama twierdzi, że możesz mieć ~ 2,5 miliona aktorów tylko na 1 GB sterty. Porównaj to, co robi typowy system, a właściwie nic.

Jeśli chodzi o cykl życia, tworzenie aktora nie jest dużo cięższe niż tworzenie instancji klasy i skrzynki pocztowej, więc nie oczekuję, że będzie tak znaczący.
Mówiąc to, zazwyczaj nie masz wielu aktorów w swoim systemie, którzy poradzą sobie z jedną wiadomością i umrą. Normalnie pojawia się aktorów, którzy żyją znacznie dłużej. Na przykład aktor, który oblicza spłatę kredytu hipotecznego na podstawie parametrów, które podajesz, nie ma żadnego powodu, aby w ogóle umrzeć.
Również Akka sprawia, że ​​korzystanie z puli aktorów jest bardzo proste (różne rodzaje).
Więc wydajność tutaj jest bardzo podkręcona.

Ostatnia kwestia dotyczy porównania obciążenia Akka w kontekście. Na przykład, jeśli system wykonuje kwerendy bazy danych lub obsługuje/wykonuje żądania HTTP, a nawet robi znaczące IO jakiegoś rodzaju, to prawdopodobnie obciążenie związane z tymi działaniami sprawia, że ​​obciążenie Akki jest tak nieznaczne, że nawet nie pomyślałbyś o tym. Jak przelot do DB za 50 milis byłby równoważny napowietrzeniu z ~ 2,5 miliona komunikatów akka. Czy to ma znaczenie?

A więc, czy możesz znaleźć scenariusz skrajnego przypadku, w którym Akka zmusiłaby cię do zapłacenia kary za wyniki? Prawdopodobnie. Akka nie jest złotym młotem (i nic nie jest).
Biorąc to wszystko pod uwagę, powinieneś pomyśleć, czy to Akka jest wąskim gardłem wydajności w twoim konkretnym kontekście, czy marnujesz czas na mikrooptymalizację.