Handel wysokiej częstotliwości w JVM z Scala / Akka

Wyobraźmy sobie hipotetyczny system HFT w Javie, wymagający (bardzo) małych opóźnień, z dużą ilością krótkotrwałych małych obiektów, nieco ze względu na niezmienność (Scala?), tysiące połączeń na sekundę i obsceniczna liczba komunikatów przekazywanych w architekturze opartej na zdarzeniach (akka i amqp?).

Dla ekspertów jaki (hipotetycznie) byłby najlepszy tuning do JVM 7? Jaki Kod by go uszczęśliwił? Czy Scala i Akka będą gotowe na tego typu systemy?

Notatka: było kilka podobnych pytań, takich jak to one , ale jeszcze nie znalazłem jednego obejmującego Scalę(która ma swój własny, idiosynkratyczny footprint w JVM).

Author: Community, 2012-03-31
Source

3 answers

Na moim laptopie średnie opóźnienie komunikatów ping pomiędzy Akka 2.3.7 wynosi ~300ns i jest znacznie mniejsze niż oczekiwane opóźnienie z powodu przerw GC na JVMs.

Kod (incl. Opcje JVM) i wyniki testów dla Akka i innych aktorów na Intel Core i7-2640M tutaj.

P. S. wiele zasad i wskazówek dotyczących obliczeń z niskim opóźnieniem można znaleźć na stronie Dmitrija Vyukova oraz na blogu Martina Thompsona .

 26
Author: Andriy Plokhotnyuk,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-15 15:39:21

Możliwe jest osiągnięcie bardzo dobrej wydajności w Javie. Jednak pytanie to musi być bardziej szczegółowe, aby dostarczyć wiarygodnej odpowiedzi. Twoje główne źródła opóźnienia będą pochodzić z poniższej niewyczerpującej listy:

  1. Ile śmieci tworzysz i praca GC do zbierania i Promuj to. Niezmienne wzory z mojego doświadczenia nie pasują dobrze do małe opóźnienie. GC tuning musi być duży nacisk.

  2. Rozgrzej JVM tak, aby klasy były ładowane i JIT has had time aby wykonać swoją pracę.

  3. Zaprojektuj swoje algorytmy NA O(1) lub co najmniej O (log2 n) i miej testy wydajności, które to potwierdzają.

  4. Twój projekt musi być wolny od blokad i podążać za " Single Writer Zasada ".

  5. Należy włożyć znaczny wysiłek w zrozumienie całości stosu i okazując mechaniczną sympatię w jego użyciu.

  6. Zaprojektuj swoje algorytmy i struktury danych tak, aby były przyjazne dla pamięci podręcznej. Brak pamięci podręcznej te dni są największym kosztem. Jest to ściśle związane z powinowactwem procesowym, które jeśli nie zostanie prawidłowo skonfigurowane, może spowodować i znaczne zanieczyszczenie pamięci podręcznej. Będzie to wiązało się z sympatią dla systemu operacyjnego, a nawet niektórych kodów JNI w niektórych przypadkach.

  7. Upewnij się, że masz wystarczającą ilość rdzeni, aby każdy wątek, który musi run ma rdzeń dostępny bez konieczności czekania.

Ostatnio pisałem na blogu o studium przypadku takiego ćwiczenia.

 34
Author: Martin Thompson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-04 11:28:20

Może się okazać, że użycie bufora pierścieniowego do przekazywania wiadomości przewyższy to, co można zrobić z Akką. Główną implementacją bufora pierścieniowego, której ludzie używają w JVM do zastosowań finansowych, jest Disruptor, który jest starannie dostrojony pod kątem wydajności( moc dwóch rozmiarów), dla JVM (bez GC, bez blokad) i dla nowoczesnych procesorów (bez fałszywego udostępniania linii pamięci podręcznej).

Oto prezentacja intro z punktu widzenia Scali http://scala-phase.org/talks/jamie-allen-sdisruptor/index.html#1 i są linki na ostatnim slajdzie do oryginalnego materiału LMAX.

 11
Author: Michael Dillon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-03 03:52:04