Czy powinienem używać Spring Scone Scoped beans lub cache takich jak ehcache?

Question

Mamy aplikację, która musi utrzymywać stan, aby niektóre obiekty zawierające dane (potencjalnie dużo) mogły zostać przesłuchane przez klienta (przeglądarkę) w interakcji "konwersacyjnej". Przy każdym żądaniu nie byłoby wydajne przeładowywanie danych.

Używamy ziaren Spring i session scoped do utrzymywania danych kontrolowanych przez sesję. Jednak te nowe ziarna będą większe.

Czy byłoby to właściwe użycie ziaren o rozmiarze sesji, czy też lepiej byłoby użyć pamięci podręcznej (ehcache)?

Nie chcemy wprowadzać technologii buforowania, chyba że naprawdę musimy.

Innym czynnikiem jest to, że aplikacja będzie musiała zostać wdrożona w klastrze. W takim przypadku ziarno o rozmiarze sesji może być replikowane przez sesyjną replikację serwera aplikacji, czy bardziej efektywne byłoby korzystanie z ehcache (które, jak sądzę, może być rozpowszechniane w klastrze)?

Wszelkie wskazówki są mile widziane.

Answer 1

Kilka myśli na ten temat (Zastrzeżenie: Pracuję dla terakota/ehcache ... więc miej to na uwadze ... ale nadal stara się być bezstronny tutaj):

1 - Czy istnieją jakieś nadmiarowe dane każda z sesji? Coś, co można udostępniać w sesjach? Jeśli tak, +1 dla ehcache do przechowywania udostępnionych rzeczy (ponieważ ehcache jest zoptymalizowany pod kątem dużej współbieżności)

2 - Jak duże są twoje obiekty sesji? I ilu równoczesnych użytkowników oczekujesz w stanie stabilnym? (innymi słowy, ile pamięci będziesz musiał poświęcić na przechowywanie sesji na serwerze aplikacji?)

Jeśli ślad sesji nie jest ogólnie taki ogólny i może ładnie zmieścić się w sterty bez problemów z GC, to używając sesji powinno być dobrym rozwiązaniem.

Ale im większy, tym większy będzie twój stertę java ... i tym bardziej będziesz musiał używać sztuczek voodoo, aby utrzymać w pamięci zbiory śmieci i gp pauzy. Korzystając z ehcache, możesz przechowywać centralnie niektóre obiekty, do których wiele sesji może uzyskać dostęp ... a więc konsolidować swój ślad pamięci (ten sam punkt, co 1). Dodatkowo, używając rozszerzenia Enterprise dla ehcache (BigMemory = http://terracotta.org/products/bigmemory), możesz ominąć stertę ograniczenia i przechowuj swoje dane poza stertami (w miarę potrzeb - 10, 100 lub więcej GB). Z tego powodu rozmiar obiektów, które muszą znajdować się w pamięci, staje się nieistotny (o ile można oczywiście dodać pamięć RAM do serwera).

3 - Do replikacji sesji, serwery aplikacji, takie jak JBOSS, Weblogic, wsparcie dla Websphere to. Ponownie, jest to kwestia wielkości sesji (ile danych będzie musiało być powtórzonych na drucie). Jeśli obiekty sesji są duże i wielu z nich będzie dużo ruchu sieciowego w klastrze ... może lub nie może działać dobrze. Posiadanie podstawowych obiektów w rozproszonej warstwie EhCache zoptymalizowanej pod kątem przechowywania danych, przy zachowaniu minimalnej sesji (tj. Informacji logowania/uwierzytelniania) zdecydowanie poprawiłoby ten mechanizm replikacji sesji, moim zdaniem.

Nadzieję, że pomaga.