Wydajność i bezpieczeństwo JasperReports Server

13 listopada 2015, Mariusz Skóra

Zainstalowany i wstępnie skonfigurowany serwer wydruku w pełni realizuje zlecone zadanie. Jednak wraz z wdrożeniem rodzi się wiele pytań. Czy przyjęte rozwiązanie jest wydajne i bezpieczne? Jak wiele żądań można obsłużyć jednocześnie? Czy wywołując tylko adres URL dokumentu, każdy może podejrzeć plik, którego nie powinien zobaczyć?

Ten artykuł jest częścią serii o TIBCO Jaspersoft JasperReports. W celu dostępu do pozostałych artykułów, proszę wybrać odpowiedni z poniższej listy. Lista aktualizowana jest na bieżąco wraz z udostępnianiem kolejnych artykułów. Jeżeli artykuł nie jest dostępny, znaczy to, że jeszcze oczekuje na publikację.

1. Wstęp do JasperReports Server.

2. Jak zrobić prosty szablon faktury. Wstęp do Jaspersoft Studio.

3. Integracja Jaspersoft Studio z JasperReport Server.

4. Integracja JasperReports Server z aplikacją w Oracle APEX.

5. Wydajność i bezpieczeństwo JasperReports Server.

6. Inne metody drukowania dokumentów.

Cel testów

Celem testów było sprawdzenie czasów odpowiedzi oraz odporności na dużą ilość jednoczesnych żądań do  JasperReports Server. Po instalacji serwera, domyślne ustawienia ustalone są na maksymalną obsługę 100 użytkowników jednocześnie. W dokumentacji Jaspersoft można znaleźć informację jak zmienić te ustawienia, aby serwer przyjmował większą ilość jednoczesnych żądań od użytkowników.

Wymagania JasperReports Server

Zgodnie z dokumentacją Jaspersoft, minimalne i rekomendowane wymagania dla serwera przy instalacji JasperReports Server są następujące:

Zasoby Minimum Zalecane
HDD 10GB 40GB+
RAM 4GB 8GB+
CPU 2 rdzenie 2.5GHz + wiele-rdzeni

Przy czym zgodnie z informacją firmy Jaspersoft, zalecane parametry powinny być traktowane jako przykład. Produkcyjny system w praktyce może wymagać mniej lub więcej zasobów niż zakłada to dokumentacja. Zależy to od obciążenia, liczby aktywnych użytkowników, zapytań do bazy danych oraz konfiguracji tej bazy oraz od tego czy baza i aplikacja JRS zainstalowana jest na tej samej maszynie.

Testowany JRS zainstalowany jest na komputerze lokalnym. Na tym samym komputerze jest również baza PostgreSQL (repozytorium JRS) oraz Oracle (dane faktury).

Narzędzia

Do analizy wydajności JasperReports Server wykorzystano program Apache JMeter 2.13, do pobrania tutaj. Za przykładowy raport służył szablon faktury udostępniony w tej serii artykułów.

Przypadki testowe

Przeprowadzono następujący scenariusz testowy (opis w języku Gherkin):

Id Element modułu / Akcja Opis
1 REST Web Service API – wydruk dokumentu gdy użytkownik zaloguje się w systemie przez adres URL
i otworzy adres URL dokumentu PDF
  wtedy system wyświetli plik PDF na ekranie

Wyniki testów

Poniżej przedstawiono podsumowanie zagregowanych wyników z programu Jmeter.  Podsumowanie agreguje wszystkie pojedyncze żądania URL.

Test 1. Scenariusz (1): REST Web Service API – eksport faktury do PDF

Ustawienia: Tomcat (context.xml): maxActive = 100; PostgreSQL (postgresql.conf): max_connections = 100

ID Testu Liczba użytkowników Średnia [ms] Mediana [ms] Min [ms] Max [ms] % błędów Przepustowość
KB/s
KB/sek
1 1 478 478 478 478 0 2,1 17,5
2 10 1584 1647 853 1811 0 4 33,4
3 25 3277 3411 588 4369 0 5,2 43
4 50 4774 5027 2363 6135 0 7,4 61,4
5 75 8355 8868 4611 10338 0 7 58,4
6 100 9212 9940 3318 12552 26 7,4 70,6
7 150 12075 13099 4315 18997 50,67 7,9 62,7
8 200 11923 10199 4983 22099 65,5 8,9 77,8
9 300 14813 13653 2285 26933 64,67 10,6 155,2
10 500 18334 18262 1914 35283 81,4 12,2 114

Test 2.  Scenariusz (1): REST Web Service API – eksport faktury do PDF

Ustawienia: Tomcat (context.xml): maxActive = 1000; PostgreSQL (postgresql.conf): max_connections = 1000

ID Testu Liczba użytkowników Średnia [ms] Mediana [ms] Min [ms] Max [ms] % błędów Przepustowość KB/sek
1 1 419 419 419 419 0 2,4 19,9
2 10 1812 1784 1399 2221 0 3,6 30,3
3 25 3181 3441 1876 4250 0 5,5 45,6
4 50 5520 5781 2418 6822 0 7 58,2
5 75 8674 9224 5524 10726 0 6,7 55,6
6 100 14861 15273 7643 17065 0 5,7 47,8
7 150 23251 24459 7227 26967 0 5,4 45,2
8 200 28066 30138 11705 34233 0 5,7 48
9 300 34291 38923 1713 46599 0 5,9 49,2
10 500 60748 64059 1118 87200 0 5,4 45,3
11 1000 98819 99418 977 160420 0 5,9 48,9
12 1100 102113 102518 16893 166046 0 6,2 51,5
13 1500 135774 135476 1125 223970 0 6,1 50,7
14 2000 176384 175358 43115 293255 0 5,9 49,6
15 3000 276898 268815 788 456270 0 5,4 45,5
16 4000 387391 372773 1308 613975 0 4,9 40,7
17 5000 567229 540106 1917 828373 0 3,8 31,5

Wnioski

Na wstępie wniosków należy napisać, że testy wykonywane były laptopie HP ProBook 6570b przy standardowej konfiguracji usług Tomcat, Oracle i PostgreSQL, a nie w warunkach laboratoryjnych. Dane należy traktować tylko poglądowo, a nie jako pewne dane o systemie.

Celem tego testu było pokazanie jak JasperReports Server zachowuje się przy maksymalnej puli obsługiwanych żądań jednocześnie. Widać, że JRS radzi sobie całkiem nieźle gdy ustawimy wartość 1000 za maksymalną liczbę jednoczesnych połączeń. Jednak wraz ze wzrostem maksymalnej puli rośnie średni czas obsługi żądania. Wynika to z pracy bazy danych, która ze względu na konfigurację przydziela mniejszą ilość zasobów na jedno połączenie. Inaczej ma się to przy 100 jednoczesnych połączeniach do bazy. Średni czas obsługi jednego żądania jest niższy, ale problem pojawia się już przy próbie obsługi maksymalnej liczby jednoczesnych połączeń. Liczba nieobsłużonych żądań (kod HTTP 500 lub 403) rośnie wraz z wyższą liczba połączonych użytkowników.

Istnieje wiele sposobów jak usprawnić działanie serwera, gdy z jakiegoś powodu spodziewamy się dużej ilości jednoczesnych połączeń lub gdy próbujemy przesłać duża ilość danych protokołem HTTP.

1. Zawsze należy pisać optymalne zapytania SQL. Zwracaj uwagę na koszt zapytania i optymalizuj tam gdzie to możliwe.

2. Jeżeli twoje szablony zwracają dużo treści, pomyśl o kompresji pakietów HTTP, aby zmniejszyć kolejki na serwerze aplikacji. Więcej na ten temat tutaj.

3. Jeżeli często wykonujesz ten sam raport, pomyśl o buforze dla plików statycznych takich jak pliki CSS, obrazy. Więcej na ten temat tutaj.

4. Serwer Tomcat domyślnie monitoruje zmiany aplikacji na dysku i wdraża ją ponownie gdy zaszły jakieś zmiany. To zachowanie obciąża procesor i pamięć RAM i zalecane jest aby wyłączyć tę usługę. Więcej na ten temat tutaj.

Zachęcam do zapoznania się z dokumentacją Jaspersoft pod tym linkiem, gdzie można znaleźć więcej szczegółów.

Ponadto, można połączyć wiele serwerów JasperReports Server w klaster, bez względu czy to wersja komercyjna czy darmowa. Znaczy to, że JRS może pracować w trybie wysokiej dostępności (high-availability). Warunkiem jest, aby instancje JRS były identyczne (taka sama wersja i konfiguracja). Więcej na ten temat można znaleźć w dokumentacji.

Bezpieczeństwo

Ważną kwestią bezpieczeństwa jest pewność, że użytkownik widzi to co powinien widzieć. Jedna instancja JasperReports Server może pracować na wielu danych z różnych zbiorów co rodzi niepewność, czy użytkownicy będą mieć integralne dostępy do zasobów im przeznaczonych. W takiej sytuacji chcemy aby użytkownicy widzieli tylko te dane, które są im przeznaczone. Jest to ważna kwestia bezpieczeństwa, aby zapewnić integralność widoków, które udostępniamy naszym użytkownikom. Na całe szczęście JRS umożliwia taką konfigurację, aby zabezpieczyć nasze dane przed dostępem osób nieautoryzowanych.

  1. Użytkownicy posiadają swoje integralne uprawnienia, które z kolei możemy wiązać łącząc konta w grupy. Każde konto chronione jest hasłem.
  2. Administrator definiuje do jakich obiektów mają dostęp użytkownicy i grupy użytkowników.
  3. Instancja JasperReports Server może obsługiwać wiele organizacji. Każda organizacja jest izolowana od pozostałych (za wyjątkiem zasobów publicznych). Do organizacji mogą należeć całe grupy użytkowników, a ponadto każda organizacja może mieć własnego administratora. Usługa dostępna jest tylko w wersji Professional. Więcej informacji można znaleźć tutaj.

Autoryzacja użytkowników

W JasperReports Server każda grupa może zawierać dowolną liczbę użytkowników, a każdy użytkownik może być w wielu grupach jednocześnie, przy czym posiada wszystkie uprawnienia grup do których należy. Pozostaje kwestia sposobu autoryzacji użytkowników w systemie. JasperReports oferuje wiele możliwości. Między innymi:

  • autoryzacja LDAP,
  • Centralny System Uwierzytelniania, ang.: CAS,
  • Java Authentication and Authorization Service (JAAS),
  • logowanie anonimowe,
  • inne takie jak SiteMinder, Container security.

Podsumowanie

Artykuł powstał w oparciu o dokumentację Jaspersoft i własne doświadczenia. Przeprowadzone testy powinny być traktowane poglądowo, a na ich podstawie nie powinno się podejmować biznesowych decyzji. Pomijając ten fakt, testy wykazały że JRS radzi sobie stabilnie z wieloma żądaniami wykonywanymi jednocześnie. Ponad wszystko warto pamiętać o własnej pracy i że za działanie naszych produktów w dużej mierze odpowiadamy my sami.

Tagi: , , , , , , , , , , , , ,

Zapraszamy do kontaktu!

Pretius jest firmą tworząca oprogramowanie wspierające biznes.
Tworzymy aplikacje webowe wykorzystując: Java, Oracle DB, Oracle Apex, AngularJS.
Skontaktuj się z nami, aby porozmawiać o tym jak możemy pomóc w realizacji Twojego projektu!