Ślad pamięci dla dużych systemów w Vaadin

Question

Pracuję w sektorze finansowym, a my zamierzamy wybrać Vaadin 7 do opracowania systemu dużych ciężkich ładunków.

Ale trochę martwię się o ślad pamięci Vaadina dla dużych systemów, ponieważ Vaadin utrzymuje wszystkie stan sesji. Oznacza to, że dla każdego nowego użytkownika cały stan aplikacji będzie przechowywany w pamięci, prawda?
Nie możemy zbudować systemu monolitycznego w systemie aford - system musi być skalowalny i zwinny. Ponieważ mamy ogromną bazę klientów, musi być łatwa do dostosowania i gotowa do rozwoju.

Czy ktoś mógłby podzielić się doświadczeniem i możliwymi obejściami, jak zminimalizować lub wyeliminować te problemy w Vaadin?

Answer 1

Myślę, że powinieneś rzucić okiem tutaj: https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets

Plus, znalazłem następujące informacje od ludzi, którzy prowadzą Vaadin w produkcji.

Balázs Hódossy:

Mamy system back office z ponad 10 000 użytkowników. Codzienny numer użytkownika to około 3000, ale połowa z nich korzysta z systemu 8 godzin bez wylogowania. Używamy pakietu Tomcat Liferay 6.0.5 i Vaadin jako portletu . Nasze dwa serwery mają 48 GB pamięci RAM i dajemy stertę 24 GB Tomcat. DB ma 18 GB, a system resztę. Zmierz stertę na sesję o rozmiarze , jednoczesnych użytkownikach i aktywności. Więcej pamięci powoduje więcej, ale już dłużej pełne GC. Planujemy zwiększyć liczbę pracowników Tomcat i zmniejszyć ilość stert. Zmierzając serwer, spróbuj dodać nieco więcej pamięci. Jeśli koszt jest tak ważny, niż zmniejszenie , koszt procesora i kupić więcej pamięci RAM. Przez większość czasu jest cenne przy niewielkim strojeniu.

Pierre Emmanuel Gros:

na 1000 dayly użytkownik heavyly, otrzymuje się czysty aplikacji Vaadin: Serwer 3 GB 2 rdzenia molo z ulimit do 50000 Postgresql 9 50 użytkowników concurent (połączenia pula jest używana). Jako część oprogramowania użyłem także ehcache do buforowania obiektów DTO i czystego JDBC.

Answer 2

Podczas opracowywania naszych produktów stanęliśmy przed problemem dużego zużycia pamięci przy użyciu domyślnej architektury Vaadin.

Architektura Vaadin opiera się na komponentach sterowanych przez zdarzenia. Korzystanie z komponentów jest dość proste, aby stworzyć ściśle powiązaną aplikację. Powodem jest to, że komponenty są podzielone na hierarchię. To jest jak piramida. Większa aplikacja jest zbudowana; większa piramida jest przechowywana w sesji dla każdego użytkownika.

W celu znacznego zmniejszenia alokacji pamięci stworzyliśmy podejście oparte na stronie dla aplikacji z kompleksowym modelem zdarzeń w tle, korzystając z zarządzania stanem starej szkoły. Opiera się na zapisie Statechart w formacie XML.

W rezultacie sesja przechowuje tylko odwiedzane strony podczas przepływu pracy użytkownika, opisane przez konfigurację Statechart. Gdy użytkownik zakończy przepływ pracy, wszystkie strony zostaną zwolnione do zbierania przez garbage collector.

Aby zobaczyć różnicę, zrobiliśmy kilka testów, aby porównać pamięć przydzieloną dla użytkownika pracującego z aplikacją.

Aplikacje opracowane:

• z mocno sprzężona podejścia spożywać od 5 do 15MB sterty na użytkownika
• z luźno sprzężona podejścia - do 2 MB

Jesteśmy bardzo zadowoleni z wynikami, ponieważ pozwolił nam skalować duży system przy użyciu 4 GB pamięci RAM do 1000-1500 jednoczesnych użytkowników na serwer.

Prawie zapomniałem. Użyliśmy biblioteki Lexaden Web Flow. Jest z licencją Apache.