JSF Tuning

Question

Występuje problem, w którym JSF wypełnia nasze sesje. Poprzedniego dnia mieliśmy awarię systemu. Wysłałem Stertę do IBM w celu sprawdzenia i stwierdziliśmy, że mieliśmy sesje o wielkości nawet 50M. W trakcie sesji znaleźli komponenty JSF, a niektóre bardzo duże.

Czy istnieje możliwość strojenia? Elementy konfiguracji do obejrzenia? Lub w innym kierunku.

Nasz system jest zbudowany przy użyciu JSF i Spring dla warstwy prezentacji, a back-end to EJB, Spring i Hibernate all działający na serwerze WebSphere 6.1.

Answer 1

JSF to przydatna technologia, ale można na niej powiesić.

Wygląda na to, że albo nadmuchujesz rozmiar stanu widoku (ustawiając duże wartości na komponentach), albo przenosisz odniesienia do komponentów do innego stanu sesji (co byłoby złe). Innym potencjalnym winowajcą byłby zbyt duży widok (widziałem łatwość, z jaką ludzie mogą budować drzewa interfejsu użytkownika, prowadzą do bardzo dużych wykresów kontrolnych z tabelami danych wszędzie). Wiem, że IBM zapewnia rozbudowane mechanizmy kontroli tekstu i arkuszy kalkulacyjnych - nie mogę komentować, jaki wpływ będzie miało ich wykorzystanie na wielkość państwa.

Niskie wiszące owoce to sprawdzanie zarządzanych ziaren skonfigurowanych dla zakresu sesji w faces-config.xml.

JSF zapisuje dwie rzeczy między żądaniami:

• widok (wszystkie elementy sterujące na stronie)
• stan widok (stan kontroli)

Są one rozdzielone, ponieważ niektóre kontrolki, na przykład dzieci tabeli danych, mogą mieć wiele stanów (po jednym dla każdego wiersza). Stan można zapisać na ukrytym polu w formularzu (który, jeśli nieszyfrowany, może stanowić duże zagrożenie bezpieczeństwa) lub w sesji. Aby uwzględnić wiele okien przeglądarki współużytkujących tę samą sesję (oraz, w niektórych implementacjach, obsługę przycisku Wstecz), zapisanych jest wiele widoków.

• Powinna istnieć opcja konfiguracji do ustawiania liczby stanów wyświetlania, które aplikacja będzie przechowywać w sesji dla danego użytkownika w danym momencie.
• Możesz zmierzyć rozmiar stanu widoku, podając StateManager, który mierzy rozmiar zapisanego widoku/stanu (skonfiguruj StateManager w faces-config.xml z publicznym konstruktorem, który pobiera StateManager - więcej informacji na ten temat można znaleźć w plikach PDF: JSF spec; stan można przekształcić do postaci szeregowej, a jego rozmiar można sprawdzić, przesyłając go do strumienia).

Większość aplikacji JSF zbudowanych przez IDE ma backing beans. Byłoby możliwe, aby zakres komponentu bean sesji utrzymywał stan dłuższy, niż chcesz, kładąc nacisk na sesję. Ponieważ na jednej stronie znajduje się jeden komponent bean, im więcej stron, tym większy problem. Sprawdź swoje faces-config.xml, aby sprawdzić, czy jest to potencjalne źródło problemów.

Coś innego, co możesz zrobić, to skonfigurować HttpSessionAttributeListener w swoim web.xml. Możesz uzyskać stack trace, aby pomóc zidentyfikować obszary problemowe w aplikacji.

Answer 2

To jest drugi system, o którym słyszałem, który zmarł z powodu JSF i nadmiernego tworzenia obiektów. Drugi również używał Springa i Hibernate w tylnym końcu. Profilowanie za pomocą OptimizeIt wykazało, że odpowiedź backendu była rzędu milisekund dla wszystkich żądań, ale można by było zrezygnować z ponownego renderowania przeglądarki ze stoperem, ponieważ trwało to tak długo - 30 sekund do kilku minut. Pamięci konsumowane przez klienta były absurdalne.

Byłem tylko obserwatorem, a nie członkiem tego zespołu projektowego. Będę musiał zapytać, czy problem został kiedykolwiek naprawiony, a jeśli tak, jakie mogło być rozwiązanie.

Ale jeśli dwa punkty mają tendencję, powiedziałbym, że JSF może być fatalnie wadliwy. Osobiście trzymam się z dala od tego całkowicie.

Dlaczego nie wypróbować wstęgi sieci Spring i sprawdzić, czy to pomaga? Jeśli podążasz za idiomem Spring, powinna to być względnie prosta sprawa zastąpienia JSF JSPs i kontrolerów Spring opartych na JSTL.

Answer 3

Pracowałem nad projektem JSF i odkryłem, że mamy błąd, w którym dodawaliśmy wiele elementów JSF h: form. W rezultacie kopia całego stanu wyświetlania jest dołączana do każdego formularza. Zmniejszenie do 1 formularza na stronie ogoliło strony od ~ 2M do ~ 300K.

Answer 4

Możliwe, że masz problemy z dużą ilością ziarnistości jako zakresu sesji.

Możesz spróbować spojrzeć na MyFaces Orchestra. Jest to biblioteka, która udostępnia zakres konwersacji, więc gdy użytkownik skończy z określonym zestawem komponentów, zostaną one usunięte z sesji.

Rozumiem, że Spring WebFlow ma podobne funkcje, ale tak naprawdę nie przyjrzałem się temu!

Answer 5

JSF przechowuje widoki w sesji, aby obsługiwać bogatą architekturę opartą na komponentach (należy zachować swój stan widoku) i może wypełniać stertę, jeśli nie jest używana prawidłowo. Jeśli nie masz dużych przepływów pracy, zawsze używaj małej liczby wyświetleń na sesję. Unikaj także utrzymywania sesji w maksymalnym możliwym zakresie. Użyj niestandardowego znacznika, aby utworzyć obiekt danych tylko dla następnego cyklu żądania. Możemy również użyć Spring Web Flow z JSF, który wprowadza zakres widoku i zakres przepływu, jeśli mamy długi przepływ pracy w aplikacji, aby zmniejszyć liczbę wyświetleń skonfigurowanych w sesji. JSF może być użyty do łatwego tworzenia bogatego interfejsu użytkownika, który pomaga budować Webapplication podobny do aplikacji desktopowej. Przydziel konkretną stertę do frameworku JSF, aby wykonać swoją pracę. Ale wydajnie korzystaj z pamięci po stronie aplikacji i upewnij się, że nie ma wycieku pamięci. Wszystkie wycieki pamięci muszą zostać zbadane i poprawione podczas samego rozwoju. Zawsze używa profilera, aby znaleźć wycieki pamięci i wąskie gardła wydajności występujące w aplikacji.

Mat.

Answer 6

Jeśli korzystasz z MyFaces < 1.1.6 istnieje ogromny wyciek pamięci w sposobie, w jaki buforuje on stare sesje serializowane w czasie sesji, nigdy nie pozwalając na ich zwolnienie, aby mogły być zbierane. Miałem z tym poważny problem i miałem również sesje 50 MB. Szybkie uaktualnienie MyFaces rozwiązało problem bez żadnych problemów.

Answer 7

Skonfiguruj utrwalanie sesji do bazy danych i użyje najmniej używanego algorytmu, aby wyrzucić najmniej zużyte sesje z pamięci. Ma wysoką wydajność (gdy jest poprawnie skonfigurowany) i pomoże ci konkretnie i szybko.

Answer 8

Trochę starego tematu, ale natknąłem się na to niedawno. Często stan Widok i Widok są przechowywane (jak wcześniej wspomniano) i zapełnia sesję, aby umożliwić działanie przycisku Wstecz. Istnieją parametry do sortowania tego w deskryptorach wdrażania (web.xml), które należy ustawić.

Wiele instancji niektórych bibliotek może wymagać więcej niż jednego ustawienia parametru, na przykład podczas korzystania z MyFaces i JSF RI. Domyślnie można ustawić je na dość wysokie wartości (odpowiednio 20 i 16). Oznacza to, że możesz użyć 20 razy więcej miejsca, w którym powinieneś być (części?) Sesji.

Answer 9

wskazówki JSF strojenia dla środowiska produkcyjnego:
- Wykorzystanie obrazów, CSS i zasobów JavaScript powinny być wykonane za pomocą standardowych znaczników HTML (img,link,script) nie po stronie serwera, a należy ustawić #{request.contextPath} przed url uniknąć ścieżek względnych problemy.
- Cache statyczne sekcje za pomocą strony (menu,header,footer)omnifaces cache
- Ustaw refresh-period zmiennej na -1
- zestaw project-stage do Produkcji
- Przejrzyj swoje filtry kodu jeśli

Również Sprawdź mój artykuł „Java Server Faces in Real-Life Applications” na DZone, daje pełny obraz o JSF w środowiskach programistycznych, testowych i produkcyjnych.