<commit_before>\chapter{Wyniki testów}
Wyniki testów każdej aplikacji uruchamianej w poszczególnych przypadkach  testowych przedstawiono w formie diagramów: diagramu przedstawiającego liczbę żądań obsłużonych przez aplikację w ciągu sekundy i diagramu rozkładu czasów odpowiedzi aplikacji.

Wyniki testów podzielono na dwie grupy zależne  od początkowego stanu bazy danych.

\section{Testy z pustą bazą danych}

\subsection{Test wydajności walidacji API}
Wyniki testów wydajności walidujących istnienie klucza API przedstawiają diagramy zamieszczone na rysunkach \ref{fig:tomcat_clean_api_validation_rps} - \ref{fig:go_clean_api_validation_td}.

Z diagramów prezentujących liczbę żądań obsłużonych w ciągu sekundy przez poszczególne aplikacje (rys. \ref{fig:tomcat_clean_api_validation_rps}, \ref{fig:jetty_clean_api_validation_rps}, \ref{fig:go_clean_api_validation_rps}) wynika, że przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 9.0 do 11.0 tysięcy obsłużonych żądań. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 5.0 do 10.0 tysięcy obsłużonych żądań, przy znacznych wahaniach przepustowości. Przepustowość serwera \textsl{Tomcat} oscylowała w przedziale od 6.0 do 8.0 tysięcy obsłużonych żądań. Przy 250 klientach wydajność aplikacji w \textsl{Go} oscylowała w przedziale od 8.0 do 10.0 tysięcy obsłużonych żądań, a serwery \textsl{Jetty} i \textsl{Tomcat} obsłużyły od 4.0 do 8.0 tysięcy żądań przy dużych wahaniach przepustowości.      

Z diagramów rozkładu czasów odpowiedzi aplikacji (rys. \ref{fig:tomcat_clean_api_validation_td}, \ref{fig:jetty_clean_api_validation_td}, \ref{fig:go_clean_api_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 13.70 milisekund, dla serwera \textsl{Jetty} 11.42 milisekund, a dla aplikacji w \textsl{Go} 9,44 milisekundy. Najdłużej trwające żądania trwały około 35 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} oraz 18 milisekund przy aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} były prawie takie same i wynosiły odpowiednio 36.32 i 35.52 milisekund, a w aplikacji w \textsl{Go} 22t.47 milisekundy. Najdłużej trwające żądania trwały ponad 90 milisekund w przypadku serwera Tomcat, poniżej 88 milisekund w przypadku serwera \textsl{Jetty} i około 55 milisekundy przy aplikacji w \textsl{Go}. Dodatkowo, przy 250 klientach, dla serwerów \textsl{Tomcat} i \textsl{Jetty} rozkłady czasów odpowiedzi były spłaszczone. 

% \input{chapters/6_wyniki_testow_diagram_1_clean_api_validation.tex}
\clearpage

\subsection{Test wydajności walidacji istnienia obiektów Cache}
Wyniki testów wydajności walidacji istnienia obiektów Cache przedstawiają diagramy na rysunkach \ref{fig:tomcat_clean_key_validation_rps} - \ref{fig:go_clean_key_validation_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_clean_key_validation_rps} \ref{fig:jetty_clean_key_validation_rps}, \ref{fig:go_clean_key_validation_rps}) wynika, że przy 100 klientach największą liczbę żądań (około 7.0 tysięcy) obsłużyła aplikacja napisana w \textsl{Go}. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 3.5 do 4.5 tysiąca obsłużonych żądań, a serwera \textsl{Tomcat} w przedziale od 2.0 do 3.5 tysiąca obsłużonych żądań. Przy 250 klientach wydajność aplikacji w \textsl{Go} oscylowała w przedziale od 7.0 do 8.0 tysięcy obsłużonych żądań, serwer \textsl{Jetty} obsłużył około 3.0 tysięcy żądań, a serwer \textsl{Tomcat} od 2.0 do 3.5 tysiąca żądań.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_key_validation_td}, \ref{fig:jetty_clean_key_validation_td}, \ref{fig:go_clean_key_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 30.32 milisekund, dla serwera \textsl{Jetty} 23.32 milisekund, a dla aplikacji w \textsl{Go} 13.79 milisekund. Najdłużej trwające żądania trwały około 120 milisekund w przypadku serwera Tomcat, 45 milisekund przy \textsl{Jetty} i tylko 25 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły odpowiednio 69.97 i 76.92 milisekundy, a w aplikacji w \textsl{Go} tylko 30.75 milisekundy. Najdłużej trwające żądania trwały 250 milisekund w przypadku serwera Tomcat, okło 120 milisekund w przypadku serwera \textsl{Jetty} i tylko 65 milisekundy przy aplikacji w \textsl{Go}. Czasy odpowiedzi serwera \textsl{Tomcat} w sporej części o były dużo dłuższe niż pokazuje to średnia.

% \input{chapters/6_wyniki_testow_diagram_2_clean_key_validation.tex}
\clearpage

\subsection{Test wydajności operacji CRUD}
Wyniki testów wydajności operacji CRUD przedstawiają diagramy na rysunkach \ref{fig:tomcat_clean_crud_rps} - \ref{fig:go_clean_crud_td}.

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_clean_crud_rps}, \ref{fig:jetty_clean_crud_rps}, \ref{fig:go_clean_crud_rps}) wynika, że przy przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 4.0 do 5.0 tysięcy. Serwer \textsl{Jetty} obsługiwał ponad 2.2 tysiące żądań, a przepustowość serwera \textsl{Tomcat} oscylowała w przedziale od 2.0 do 2.5 tysiąca obsłużonych żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła od 4.5 do 6.0 tysięcy żądań, serwer \textsl{Jetty} około 2.0 tysięcy żądań, podobnie jak serwer Tomcat.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_crud_td}, \ref{fig:jetty_clean_crud_td}, \ref{fig:go_clean_crud_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 42.15  milisekund, dla serwera \textsl{Jetty} 42.41  milisekund i 20.90 milisekund dla aplikacji w \textsl{Go}.  Najdłużej trwające żądania trwały poniżej 80 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} - jednak \textsl{Jetty} miał większą liczbę obsłużonych żądań. Dla aplikacji w \textsl{Go} najdłużej trwające żądania trwały tylko 35 milisekund. Przy 250 klientach średnie czas odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty}  wynosiły  odpowiednio 107.56 i 92.32 milisekund, a w aplikacji w \textsl{Go} tylko 35.68 milisekundy. Najdłużej trwające żądania trwały 200 milisekund w przypadku serwera \textsl{Tomcat}, 180 milisekund w przypadku serwera \textsl{Jetty} i 90 milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_3_clean_crud.tex}
\clearpage

\subsection{Test wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle}
Diagramy zawierające wyniki wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle zamieszczono na rys. \ref{fig:tomcat_clean_all_rps} - \ref{fig:go_clean_all_td}.                                                                  

Z rozkładów ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_clean_all_rps}, \ref{fig:jetty_clean_all_rps}, \ref{fig:go_clean_all_rps}) wynika, że przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 7.0 do 8.0 tysięcy, a serwery \textsl{Jetty} i \textsl{Tomcat} obsługiwały od 3.0 do 4.0  tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła również od 7.0 do 8.0 tysięcy żądań, serwer \textsl{Jetty} 3.0 tysiące, a wydajność serwera \textsl{Tomcat} oscylowała na poziomie 2.5 tysiąca żądań. 
 
Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_all_td}, \ref{fig:jetty_clean_all_td}, \ref{fig:go_clean_all_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 27.30  milisekund, dla serwera \textsl{Jetty} 25.63 milisekund i 13.94 milisekund dla aplikacji w \textsl{Go}.  Najdłużej trwające żądania trwały poniżej 110 milisekund w przypadku serwera \textsl{Tomcat}, powyżej 60 milisekund przy \textsl{Jetty} i około 35 milisekund  w aplikacji w \textsl{Go}. Przy 250 klientach średnie czas odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły 86.85 i 74.48 milisekund, a w aplikacji w \textsl{Go} tylko 28.06 milisekundy. Najdłużej trwające żądania trwały poniżej 180 milisekund w przypadku serwera \textsl{Tomcat}, 150 milisekund w przypadku serwera \textsl{Jetty} i 85 milisekund przy aplikacji w \textsl{Go}.

% \input{chapters/6_wyniki_testow_diagram_4_clean_all.tex}
\clearpage

\newpage
\section{Testy z bazą wypełnioną danymi początkowymi}
\subsection{Testy wydajności walidacji API}
Diagramy zawierające wyniki wydajności walidacji API zamieszczono na rysunkach \ref{fig:tomcat_full_api_validation_rps} - \ref{fig:go_full_api_validation_td}

Z rozkładów ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. rys. \ref{fig:tomcat_full_api_validation_rps} \ref{fig:jetty_full_api_validation_rps}, \ref{fig:go_full_api_validation_rps}) wynika, że przy 100 klientach aplikacja  w \textsl{Go} obsługiwała od 9.0 do 10.0 tysięcy żądań. Wydajność serwera  \textsl{Jetty} oscylowała w przedziale od 8.0 do 10.0 tysięcy żądań. Serwer \textsl{Tomcat} obsługiwał od 5.0 do 7.0 tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsługiwała również od 8.0 do 10.0 tysięcy żądań, serwer \textsl{Jetty} od 4.0 do 8.5 tysiąca żądań przy bardzo dużych wahaniach przepustowości, a wydajność serwera \textsl{Tomcat} oscylowała w przedziale od 3.0 do 6.0 tysiąca obsłużonych żądań. 
 
Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_api_validation_td}, \ref{fig:jetty_full_api_validation_td}, \ref{fig:go_full_api_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 16.72 milisekund, dla serwera \textsl{Jetty} 10.25 milisekund i 10.24 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 45 milisekund przy serwerze \textsl{Tomcat}, 30 milisekund przy \textsl{Jetty} i 18 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły odpowiednio 67.28 i 47.00 milisekundy, a w aplikacji w \textsl{Go} 25.33 milisekundy. Najdłużej trwające żądania trwały poniżej 110 milisekund w przypadku serwera \textsl{Tomcat}, 83 milisekundy w przypadku serwera \textsl{Jetty} i 55 milisekund przy aplikacji w \textsl{Go}.

% \input{chapters/6_wyniki_testow_diagram_5_full_api_validation.tex}
\clearpage

\subsection{Test wydajności walidacji istnienia obiektów Cache}
Wyniki testów wydajności walidacji istnienia obiektów Cache przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_key_validation_rps} - \ref{fig:go_full_key_validation_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_full_key_validation_rps} \ref{fig:jetty_full_key_validation_rps}, \ref{fig:go_full_key_validation_rps}) wynika, że przy 100 klientach przepustowość aplikacji w \textsl{Go} kształtowała się w przedziale od 5.0 do 6.0 tysięcy żądań. Należy zaznaczyć, że przepustowość ta została osiągniętą po upływie 3 minut od rozpoczęcia testu. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 4.0 do 5.0 tysięcy obsłużonych żądań, a serwera \textsl{Tomcat} od 2.0 do 3.0 tysięcy obsłużonych żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła od 5.0 do 6.0 tysięcy żądań również po upływie 3 minut od rozpoczęcia testu, serwer \textsl{Jetty} około 3.0 tysięcy żądań, a serwer \textsl{Tomcat} od 2.0 do 3.0 tysiąca żądań.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_key_validation_td}, \ref{fig:jetty_full_key_validation_td}, \ref{fig:go_full_key_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 38.00 milisekund, dla serwera \textsl{Jetty} 22.15 milisekund i 19.75 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały 150 milisekund przy serwerze  \textsl{Tomcat}, około 40 milisekund na serwerze \textsl{Jetty} i tyle samo w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły 86.73 i 82.37 milisekundy, a w aplikacji w \textsl{Go} 40.66 milisekundy. Najdłużej trwające żądania trwały 250 milisekund w przypadku serwera  \textsl{Tomcat}, 120 milisekund w przypadku serwera \textsl{Jetty} i poniżej 100  milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_6_full_key_validation.tex}
\clearpage

\subsection{Test wydajności operacji CRUD}

Wyniki testów wydajności walidacji istnienia operacji CRUD przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_crud_rps} - \ref{fig:go_full_crud_td}.

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_full_crud_rps} \ref{fig:jetty_full_crud_rps}, \ref{fig:go_full_crud_rps}) wynika, że przy 100 i 250 klientach poszczególne aplikacje zachowywały się porównywalnie. Przepustowość aplikacji w \textsl{Go} wahała się na od 0.5 do 3.0 tysięcy obsłużonych żądań, serwer \textsl{Jetty} obsługiwał od 0.5 do ponad 2.0 tysięcy żądań, a serwer \textsl{Tomcat} od 0.5 do około 1.5 tysiąca żądań. Dla każdej z aplikacji występowały spadki przepustowości nawet poniżej 500 żądań/s.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_crud_td}, \ref{fig:jetty_full_crud_td}, \ref{fig:go_full_crud_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 61.57 milisekund, dla serwera \textsl{Jetty} 50.04 milisekundy i 32.26 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 130 milisekund przy serwerze  \textsl{Tomcat}, 0koło 100 milisekund przy serwerze \textsl{Jetty} i poniżej 70 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty}  wynosiły odpowiednio 128.07 i 101.60 milisekund, a w aplikacji w \textsl{Go} tylko 48.96 milisekundy. Najdłużej trwające żądania trwały około 300 milisekund w przypadku serwera  \textsl{Tomcat}, 240 milisekund w przypadku serwera \textsl{Jetty} i poniżej 170 milisekund przy aplikacji w \textsl{Go}.

% \input{chapters/6_wyniki_testow_diagram_7_full_crud.tex}
\clearpage

\subsection{Test wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle}

Wyniki testów wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_all_rps} - \ref{fig:go_full_all_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_full_all_rps} \ref{fig:jetty_full_all_rps}, \ref{fig:go_full_all_rps}) wynika, że przy 100 klientach przepustowość aplikacja w \textsl{Go} kształtowała się w przedziale od 4.0 do 6.0 tysięcy obsłużonych żądań, wydajność serwera \textsl{Jetty} oscylowała w przedziale od 3.0 do 3.5 tysiąca  żądań, a  serwera \textsl{Tomcat}  obsłużył od 2.5 do 3.0 tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła również od 4.0 do 6.0 tysięcy żądań, a przepustowość serwerów \textsl{Jetty} i \textsl{Tomcat} oscylowała w przedziale od 2.0 do 3.0 tysięcy żądań. Dla każdej z aplikacji występowały spadki przepustowości nawet poniżej 500 żądań/s

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_all_td}, \ref{fig:jetty_full_all_td}, \ref{fig:go_full_all_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 35.82 milisekundy, dla serwera \textsl{Jetty} 30.10 milisekund i 19.40 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 100 milisekund przy serwerze \textsl{Tomcat}, 80 milisekund przy serwerze \textsl{Jetty} i  poniżej 50 milisekund  w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat}  i \textsl{Jetty}   wynosiły odpowiednio 96.96 i 82.34 milisekundy, a w aplikacji w \textsl{Go} tylko 38.33 milisekundy. Najdłużej trwające żądania trwały poniżej 200 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} oraz 130 milisekund w teście aplikacji w \textsl{Go}.

% \input{chapters/6_wyniki_testow_diagram_8_full_all.tex}
\clearpage

\section{Obciążenie serwerów podczas testów - pusta baza danych}
Diagramy \ref{fig:cpu_utilization_100_clean} i \ref{fig:cpu_utilization_250_clean} prezentują średnie wykorzystanie procesora maszyny, gdzie była uruchomiona testowana aplikacja podczas testu z pustą baz danych. Dane zbierane były przy pomocy programu \textsl{dstat}.

Najniższe wyniki wykorzystania procesora zaobserwowano podczas testów aplikacji \textsl{Go}. Średnio podczas testu aplikacja wykorzystywała od 29\% do 47\% procesor. Średnia wykorzystania procesora podczas testów serwerów \textsl{Tomcat} i \textsl{Jetty} było znacznie wyższe. Dla serwera \textsl{Tomcat} wartość średnia wyniosła od 40\% do 78\%, a \textsl{Jetty} od 36\% do 71\% - zależnie od grupy testów. Średnie wykorzystanie procesora podczas testów z 250 klientami było w większości przypadków niższe. Największa różnica była w grupie testów walidujących istnienie kluczy \textsl{API}

Wykorzystanie pamięci \textsl{RAM} na maszynie podczas testów nie różniło się tak bardzo. Średnio maszyna testowa podczas testu serwera \textsl{Tomcat} miała zajęte 1950 MB podczas testów 100 klientów i 2000 MB dla 250 klientów. Podczas testu serwera \textsl{Jetty} dla 100 i 250 klientów maszyna testowa miała zajęte średnio: 1900 MB i 1760 MB. W trakcie testu aplikacji w \textsl{Go} wykorzystanie pamięci na serwerze było porównywalne i wynosiło mniej niż 250 MB. 

% \input{chapters/6_wyniki_testow_diagram_obciazenia_clean.tex}

\section{Obciążenie serwerów podczas testów - baza danych wypełniona danymi początkowymi}

Diagramy \ref{fig:cpu_utilization_100_full} i \ref{fig:cpu_utilization_250_full} prezentują średnie wykorzystanie procesora maszyny, gdzie była uruchomiona testowana aplikacja podczas testu z bazą danych wypełniona danymi początkowymi. 

Najniższe wyniki wykorzystania procesora zaobserwowano podczas testów aplikacji \textsl{Go}. Średnio podczas testów aplikacja wykorzystywała od 23\% do 34\%.  procesor. Serwer \textsl{Jetty} wykorzystywał procesor między 28\% do 81\%, a \textsl{Tomcat} od 27\% do 74\%

Wykorzystanie pamięci \textsl{RAM} na maszynie podczas testów nie różniło się tak bardzo. Średnio maszyna testowa podczas testu aplikacji w języku \textsl{Go} miała zajęte 250 MB. Podczas testu serwera \textsl{Tomcat} dla 100 i 250 klientów maszyna testowa miała zajęte średnio: 1830 MB i 2030 MB. Natomiast podczas testu serwera \textsl{Jetty} pamięć zajęta była w okolicy 2010 MB. 

\input{chapters/6_wyniki_testow_diagram_obciazenia_full.tex}
\clearpage

\newpage
\section{Interpretacja wyników}

Z przeprowadzonych testów wynika, że aplikacja w języku \textsl{Go} osiągała najlepsze rezultaty przepustowości jak i czasów odpowiedzi. Wyniki przepustowości, niezależnie od liczby klientów, nie różniły się. Na uwagę zasługuje fakt, że gdy liczba klientów była większa, liczba obsługiwanych żądań w ciągu sekundy nie spadała, mimo iż czasy odpowiedzi żądań były wyraźnie dłuższe, dzięki wykorzystywaniu przez język opisywanych \textsl{go routine}.

Aplikacja w języku \textsl{Java} osiągała wyraźnie niższe rezultaty przepustowości, szczególnie podczas testów z 250 klientami. Porównując wyniki testów 100 i 250 klientów można zaobserwować mniejszą liczbę przetworzonych żądań, wyraźne były też chwilowe spadki przepustowości.  Czasy odpowiedzi również były dłuższe od aplikacji w \textsl{Go}. W niektórych przypadkach testowych były nawet 3 razy dłuższe. 

Analizując wyniki testowanych serwerów, na których była uruchomiona aplikacja \textsl{Java} lepsze rezultaty zaobserwowano na serwerze \textsl{Jetty}. Zarówno wyniki przepustowości oraz czasów odpowiedzi w większości przypadków testowych wykazywały przewagę nad serwerem \textsl{Tomcat}. 

Analiza wykorzystania zasobów maszyny przez poszczególne aplikacje pokazuje, że aplikacja w \textsl{Go} wymagała znacznie mniejsze zasoby od aplikacji w języku \textsl{Java}. Oznacza to, że odpowiednio konfigurując środowisko można uruchomić kilka instancji aplikacji \textsl{Go} równolegle, by lepiej wykorzystać zasoby maszyny, na której jest uruchomiona.  

Grupą testów podczas której wyniki najbardziej się wahały były testy operacji \textsl{CRUD}, które najbardziej wykorzystywały komunikację z bazą danych \textsl{MongoDB}. Podczas testów widoczne było mniejsze zużycie procesora na maszynie testowej. Najlepsze rezultaty notowano podczas testu walidacji \textsl{API}, gdzie komunikacja z bazą sprowadzała się do sprawdzenia, czy poszukiwany klucz istnieje. Ta grupa testów okazała się najbardziej wykorzystywać zasoby procesora, szczególnie podczas testów aplkiacji w języku \textsl{Java}.<commit_msg>analiza<commit_after>\chapter{Wyniki testów}
Wyniki testów każdej aplikacji uruchamianej w poszczególnych przypadkach  testowych przedstawiono w formie diagramów: diagramu przedstawiającego liczbę żądań obsłużonych przez aplikację w ciągu sekundy i diagramu rozkładu czasów odpowiedzi aplikacji.

Wyniki testów podzielono na dwie grupy zależne  od początkowego stanu bazy danych.

\section{Testy z pustą bazą danych}

\subsection{Test wydajności walidacji API}
Wyniki testów wydajności walidujących istnienie klucza API przedstawiają diagramy zamieszczone na rysunkach \ref{fig:tomcat_clean_api_validation_rps} - \ref{fig:go_clean_api_validation_td}.

Z diagramów prezentujących liczbę żądań obsłużonych w ciągu sekundy przez poszczególne aplikacje (rys. \ref{fig:tomcat_clean_api_validation_rps}, \ref{fig:jetty_clean_api_validation_rps}, \ref{fig:go_clean_api_validation_rps}) wynika, że przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 9.0 do 11.0 tysięcy obsłużonych żądań. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 5.0 do 10.0 tysięcy obsłużonych żądań, przy znacznych wahaniach przepustowości. Przepustowość serwera \textsl{Tomcat} oscylowała w przedziale od 6.0 do 8.0 tysięcy obsłużonych żądań. Przy 250 klientach wydajność aplikacji w \textsl{Go} oscylowała w przedziale od 8.0 do 10.0 tysięcy obsłużonych żądań, a serwery \textsl{Jetty} i \textsl{Tomcat} obsłużyły od 4.0 do 8.0 tysięcy żądań przy dużych wahaniach przepustowości.      

Z diagramów rozkładu czasów odpowiedzi aplikacji (rys. \ref{fig:tomcat_clean_api_validation_td}, \ref{fig:jetty_clean_api_validation_td}, \ref{fig:go_clean_api_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 13.70 milisekund, dla serwera \textsl{Jetty} 11.42 milisekund, a dla aplikacji w \textsl{Go} 9,44 milisekundy. Najdłużej trwające żądania trwały około 35 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} oraz 18 milisekund przy aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} były prawie takie same i wynosiły odpowiednio 36.32 i 35.52 milisekund, a w aplikacji w \textsl{Go} 22t.47 milisekundy. Najdłużej trwające żądania trwały ponad 90 milisekund w przypadku serwera Tomcat, poniżej 88 milisekund w przypadku serwera \textsl{Jetty} i około 55 milisekundy przy aplikacji w \textsl{Go}. Dodatkowo, przy 250 klientach, dla serwerów \textsl{Tomcat} i \textsl{Jetty} rozkłady czasów odpowiedzi były spłaszczone. 

\input{chapters/6_wyniki_testow_diagram_1_clean_api_validation.tex}
\clearpage

\subsection{Test wydajności walidacji istnienia obiektów Cache}
Wyniki testów wydajności walidacji istnienia obiektów Cache przedstawiają diagramy na rysunkach \ref{fig:tomcat_clean_key_validation_rps} - \ref{fig:go_clean_key_validation_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_clean_key_validation_rps} \ref{fig:jetty_clean_key_validation_rps}, \ref{fig:go_clean_key_validation_rps}) wynika, że przy 100 klientach największą liczbę żądań (około 7.0 tysięcy) obsłużyła aplikacja napisana w \textsl{Go}. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 3.5 do 4.5 tysiąca obsłużonych żądań, a serwera \textsl{Tomcat} w przedziale od 2.0 do 3.5 tysiąca obsłużonych żądań. Przy 250 klientach wydajność aplikacji w \textsl{Go} oscylowała w przedziale od 7.0 do 8.0 tysięcy obsłużonych żądań, serwer \textsl{Jetty} obsłużył około 3.0 tysięcy żądań, a serwer \textsl{Tomcat} od 2.0 do 3.5 tysiąca żądań.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_key_validation_td}, \ref{fig:jetty_clean_key_validation_td}, \ref{fig:go_clean_key_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 30.32 milisekund, dla serwera \textsl{Jetty} 23.32 milisekund, a dla aplikacji w \textsl{Go} 13.79 milisekund. Najdłużej trwające żądania trwały około 120 milisekund w przypadku serwera Tomcat, 45 milisekund przy \textsl{Jetty} i tylko 25 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły odpowiednio 69.97 i 76.92 milisekundy, a w aplikacji w \textsl{Go} tylko 30.75 milisekundy. Najdłużej trwające żądania trwały 250 milisekund w przypadku serwera Tomcat, okło 120 milisekund w przypadku serwera \textsl{Jetty} i tylko 65 milisekundy przy aplikacji w \textsl{Go}. Czasy odpowiedzi serwera \textsl{Tomcat} w sporej części o były dużo dłuższe niż pokazuje to średnia.

\input{chapters/6_wyniki_testow_diagram_2_clean_key_validation.tex}
\clearpage

\subsection{Test wydajności operacji CRUD}
Wyniki testów wydajności operacji CRUD przedstawiają diagramy na rysunkach \ref{fig:tomcat_clean_crud_rps} - \ref{fig:go_clean_crud_td}.

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_clean_crud_rps}, \ref{fig:jetty_clean_crud_rps}, \ref{fig:go_clean_crud_rps}) wynika, że przy przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 4.0 do 5.0 tysięcy. Serwer \textsl{Jetty} obsługiwał ponad 2.2 tysiące żądań, a przepustowość serwera \textsl{Tomcat} oscylowała w przedziale od 2.0 do 2.5 tysiąca obsłużonych żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła od 4.5 do 6.0 tysięcy żądań, serwer \textsl{Jetty} około 2.0 tysięcy żądań, podobnie jak serwer Tomcat.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_crud_td}, \ref{fig:jetty_clean_crud_td}, \ref{fig:go_clean_crud_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 42.15  milisekund, dla serwera \textsl{Jetty} 42.41  milisekund i 20.90 milisekund dla aplikacji w \textsl{Go}.  Najdłużej trwające żądania trwały poniżej 80 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} - jednak \textsl{Jetty} miał większą liczbę obsłużonych żądań. Dla aplikacji w \textsl{Go} najdłużej trwające żądania trwały tylko 35 milisekund. Przy 250 klientach średnie czas odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty}  wynosiły  odpowiednio 107.56 i 92.32 milisekund, a w aplikacji w \textsl{Go} tylko 35.68 milisekundy. Najdłużej trwające żądania trwały 200 milisekund w przypadku serwera \textsl{Tomcat}, 180 milisekund w przypadku serwera \textsl{Jetty} i 90 milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_3_clean_crud.tex}
\clearpage

\subsection{Test wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle}
Diagramy zawierające wyniki wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle zamieszczono na rys. \ref{fig:tomcat_clean_all_rps} - \ref{fig:go_clean_all_td}.                                                                  

Z rozkładów ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_clean_all_rps}, \ref{fig:jetty_clean_all_rps}, \ref{fig:go_clean_all_rps}) wynika, że przy 100 klientach największą liczbę żądań obsłużyła aplikacja napisana w \textsl{Go} - od 7.0 do 8.0 tysięcy, a serwery \textsl{Jetty} i \textsl{Tomcat} obsługiwały od 3.0 do 4.0  tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła również od 7.0 do 8.0 tysięcy żądań, serwer \textsl{Jetty} 3.0 tysiące, a wydajność serwera \textsl{Tomcat} oscylowała na poziomie 2.5 tysiąca żądań. 
 
Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_clean_all_td}, \ref{fig:jetty_clean_all_td}, \ref{fig:go_clean_all_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 27.30  milisekund, dla serwera \textsl{Jetty} 25.63 milisekund i 13.94 milisekund dla aplikacji w \textsl{Go}.  Najdłużej trwające żądania trwały poniżej 110 milisekund w przypadku serwera \textsl{Tomcat}, powyżej 60 milisekund przy \textsl{Jetty} i około 35 milisekund  w aplikacji w \textsl{Go}. Przy 250 klientach średnie czas odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły 86.85 i 74.48 milisekund, a w aplikacji w \textsl{Go} tylko 28.06 milisekundy. Najdłużej trwające żądania trwały poniżej 180 milisekund w przypadku serwera \textsl{Tomcat}, 150 milisekund w przypadku serwera \textsl{Jetty} i 85 milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_4_clean_all.tex}
\clearpage

\newpage
\section{Testy z bazą wypełnioną danymi początkowymi}
\subsection{Testy wydajności walidacji API}
Diagramy zawierające wyniki wydajności walidacji API zamieszczono na rysunkach \ref{fig:tomcat_full_api_validation_rps} - \ref{fig:go_full_api_validation_td}

Z rozkładów ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. rys. \ref{fig:tomcat_full_api_validation_rps} \ref{fig:jetty_full_api_validation_rps}, \ref{fig:go_full_api_validation_rps}) wynika, że przy 100 klientach aplikacja  w \textsl{Go} obsługiwała od 9.0 do 10.0 tysięcy żądań. Wydajność serwera  \textsl{Jetty} oscylowała w przedziale od 8.0 do 10.0 tysięcy żądań. Serwer \textsl{Tomcat} obsługiwał od 5.0 do 7.0 tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsługiwała również od 8.0 do 10.0 tysięcy żądań, serwer \textsl{Jetty} od 4.0 do 8.5 tysiąca żądań przy bardzo dużych wahaniach przepustowości, a wydajność serwera \textsl{Tomcat} oscylowała w przedziale od 3.0 do 6.0 tysiąca obsłużonych żądań. 
 
Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_api_validation_td}, \ref{fig:jetty_full_api_validation_td}, \ref{fig:go_full_api_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 16.72 milisekund, dla serwera \textsl{Jetty} 10.25 milisekund i 10.24 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 45 milisekund przy serwerze \textsl{Tomcat}, 30 milisekund przy \textsl{Jetty} i 18 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły odpowiednio 67.28 i 47.00 milisekundy, a w aplikacji w \textsl{Go} 25.33 milisekundy. Najdłużej trwające żądania trwały poniżej 110 milisekund w przypadku serwera \textsl{Tomcat}, 83 milisekundy w przypadku serwera \textsl{Jetty} i 55 milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_5_full_api_validation.tex}
\clearpage

\subsection{Test wydajności walidacji istnienia obiektów Cache}
Wyniki testów wydajności walidacji istnienia obiektów Cache przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_key_validation_rps} - \ref{fig:go_full_key_validation_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_full_key_validation_rps} \ref{fig:jetty_full_key_validation_rps}, \ref{fig:go_full_key_validation_rps}) wynika, że przy 100 klientach przepustowość aplikacji w \textsl{Go} kształtowała się w przedziale od 5.0 do 6.0 tysięcy żądań. Należy zaznaczyć, że przepustowość ta została osiągniętą po upływie 3 minut od rozpoczęcia testu. Wydajność serwera \textsl{Jetty} oscylowała w przedziale od 4.0 do 5.0 tysięcy obsłużonych żądań, a serwera \textsl{Tomcat} od 2.0 do 3.0 tysięcy obsłużonych żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła od 5.0 do 6.0 tysięcy żądań również po upływie 3 minut od rozpoczęcia testu, serwer \textsl{Jetty} około 3.0 tysięcy żądań, a serwer \textsl{Tomcat} od 2.0 do 3.0 tysiąca żądań.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_key_validation_td}, \ref{fig:jetty_full_key_validation_td}, \ref{fig:go_full_key_validation_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 38.00 milisekund, dla serwera \textsl{Jetty} 22.15 milisekund i 19.75 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały 150 milisekund przy serwerze  \textsl{Tomcat}, około 40 milisekund na serwerze \textsl{Jetty} i tyle samo w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty} wynosiły 86.73 i 82.37 milisekundy, a w aplikacji w \textsl{Go} 40.66 milisekundy. Najdłużej trwające żądania trwały 250 milisekund w przypadku serwera  \textsl{Tomcat}, 120 milisekund w przypadku serwera \textsl{Jetty} i poniżej 100  milisekund przy aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_6_full_key_validation.tex}
\clearpage

\subsection{Test wydajności operacji CRUD}

Wyniki testów wydajności walidacji istnienia operacji CRUD przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_crud_rps} - \ref{fig:go_full_crud_td}.

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy (rys. \ref{fig:tomcat_full_crud_rps} \ref{fig:jetty_full_crud_rps}, \ref{fig:go_full_crud_rps}) wynika, że przy 100 i 250 klientach poszczególne aplikacje zachowywały się porównywalnie. Przepustowość aplikacji w \textsl{Go} wahała się na od 0.5 do 3.0 tysięcy obsłużonych żądań, serwer \textsl{Jetty} obsługiwał od 0.5 do ponad 2.0 tysięcy żądań, a serwer \textsl{Tomcat} od 0.5 do około 1.5 tysiąca żądań. Dla każdej z aplikacji występowały spadki przepustowości nawet poniżej 500 żądań/s.

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_crud_td}, \ref{fig:jetty_full_crud_td}, \ref{fig:go_full_crud_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 61.57 milisekund, dla serwera \textsl{Jetty} 50.04 milisekundy i 32.26 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 130 milisekund przy serwerze  \textsl{Tomcat}, 0koło 100 milisekund przy serwerze \textsl{Jetty} i poniżej 70 milisekund w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat} i \textsl{Jetty}  wynosiły odpowiednio 128.07 i 101.60 milisekund, a w aplikacji w \textsl{Go} tylko 48.96 milisekundy. Najdłużej trwające żądania trwały około 300 milisekund w przypadku serwera  \textsl{Tomcat}, 240 milisekund w przypadku serwera \textsl{Jetty} i poniżej 170 milisekund przy aplikacji w \textsl{Go}.

% \input{chapters/6_wyniki_testow_diagram_7_full_crud.tex}
\clearpage

\subsection{Test wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle}

Wyniki testów wydajności walidacji API, obiektów Cache oraz operacji CRUD równolegle przedstawiają diagramy na rysunkach \ref{fig:tomcat_full_all_rps} - \ref{fig:go_full_all_td}.              

Z diagramów przedstawiających rozkład ilości żądań obsłużonych przez poszczególne aplikacje w ciągu sekundy  (rys. \ref{fig:tomcat_full_all_rps} \ref{fig:jetty_full_all_rps}, \ref{fig:go_full_all_rps}) wynika, że przy 100 klientach przepustowość aplikacja w \textsl{Go} kształtowała się w przedziale od 4.0 do 6.0 tysięcy obsłużonych żądań, wydajność serwera \textsl{Jetty} oscylowała w przedziale od 3.0 do 3.5 tysiąca  żądań, a  serwera \textsl{Tomcat}  obsłużył od 2.5 do 3.0 tysięcy żądań. Przy 250 klientach aplikacja w \textsl{Go} obsłużyła również od 4.0 do 6.0 tysięcy żądań, a przepustowość serwerów \textsl{Jetty} i \textsl{Tomcat} oscylowała w przedziale od 2.0 do 3.0 tysięcy żądań. Dla każdej z aplikacji występowały spadki przepustowości nawet poniżej 500 żądań/s

Z diagramów rozkładu czasów odpowiedzi (rys. \ref{fig:tomcat_full_all_td}, \ref{fig:jetty_full_all_td}, \ref{fig:go_full_all_td}) wynika, że przy 100 klientach średnie czasy odpowiedzi wynosiły: dla serwera \textsl{Tomcat} 35.82 milisekundy, dla serwera \textsl{Jetty} 30.10 milisekund i 19.40 milisekund dla aplikacji w \textsl{Go}. Najdłużej trwające żądania trwały poniżej 100 milisekund przy serwerze \textsl{Tomcat}, 80 milisekund przy serwerze \textsl{Jetty} i  poniżej 50 milisekund  w aplikacji w \textsl{Go}. Przy 250 klientach średnie czasy odpowiedzi aplikacji uruchamianych na serwerach \textsl{Tomcat}  i \textsl{Jetty}   wynosiły odpowiednio 96.96 i 82.34 milisekundy, a w aplikacji w \textsl{Go} tylko 38.33 milisekundy. Najdłużej trwające żądania trwały poniżej 200 milisekund w przypadku serwerów \textsl{Tomcat} i \textsl{Jetty} oraz 130 milisekund w teście aplikacji w \textsl{Go}.

\input{chapters/6_wyniki_testow_diagram_8_full_all.tex}
\clearpage

\section{Obciążenie serwerów podczas testów - pusta baza danych}
Diagramy \ref{fig:cpu_utilization_100_clean} i \ref{fig:cpu_utilization_250_clean} prezentują średnie wykorzystanie procesora maszyny, gdzie była uruchomiona testowana aplikacja podczas testu z pustą baz danych. Dane zbierane były przy pomocy programu \textsl{dstat}.

Najniższe wyniki wykorzystania procesora zaobserwowano podczas testów aplikacji \textsl{Go}. Średnio podczas testu aplikacja wykorzystywała od 29\% do 47\% procesor. Średnia wykorzystania procesora podczas testów serwerów \textsl{Tomcat} i \textsl{Jetty} było znacznie wyższe. Dla serwera \textsl{Tomcat} wartość średnia wyniosła od 40\% do 78\%, a \textsl{Jetty} od 36\% do 71\% - zależnie od grupy testów. Średnie wykorzystanie procesora podczas testów z 250 klientami było w większości przypadków niższe. Największa różnica była w grupie testów walidujących istnienie kluczy \textsl{API}

Wykorzystanie pamięci \textsl{RAM} na maszynie podczas testów nie różniło się tak bardzo. Średnio maszyna testowa podczas testu serwera \textsl{Tomcat} miała zajęte 1950 MB podczas testów 100 klientów i 2000 MB dla 250 klientów. Podczas testu serwera \textsl{Jetty} dla 100 i 250 klientów maszyna testowa miała zajęte średnio: 1900 MB i 1760 MB. W trakcie testu aplikacji w \textsl{Go} wykorzystanie pamięci na serwerze było porównywalne i wynosiło mniej niż 250 MB. 

\input{chapters/6_wyniki_testow_diagram_obciazenia_clean.tex}

\section{Obciążenie serwerów podczas testów - baza danych wypełniona danymi początkowymi}

Diagramy \ref{fig:cpu_utilization_100_full} i \ref{fig:cpu_utilization_250_full} prezentują średnie wykorzystanie procesora maszyny, gdzie była uruchomiona testowana aplikacja podczas testu z bazą danych wypełniona danymi początkowymi. 

Najniższe wyniki wykorzystania procesora zaobserwowano podczas testów aplikacji \textsl{Go}. Średnio podczas testów aplikacja wykorzystywała od 23\% do 34\%.  procesor. Serwer \textsl{Jetty} wykorzystywał procesor między 28\% do 81\%, a \textsl{Tomcat} od 27\% do 74\%

Wykorzystanie pamięci \textsl{RAM} na maszynie podczas testów nie różniło się tak bardzo. Średnio maszyna testowa podczas testu aplikacji w języku \textsl{Go} miała zajęte 250 MB. Podczas testu serwera \textsl{Tomcat} dla 100 i 250 klientów maszyna testowa miała zajęte średnio: 1830 MB i 2030 MB. Natomiast podczas testu serwera \textsl{Jetty} pamięć zajęta była w okolicy 2010 MB. 

\input{chapters/6_wyniki_testow_diagram_obciazenia_full.tex}
\clearpage

\newpage
\section{Interpretacja wyników}

Z przeprowadzonych testów wynika, że aplikacja w języku \textsl{Go} osiągała najlepsze rezultaty przepustowości jak i czasów odpowiedzi. Niezależnie od liczby klientów, osiągane wyniki nie różniły się między sobą. Na uwagę zasługuje również fakt, że gdy liczba klientów była większa to liczba obsługiwanych żądań w ciągu sekundy nie spadała tak bardzo, mimo iż czasy odpowiedzi żądań były wyraźnie dłuższe.

Aplikacja w języku \textsl{Java} osiągała wyraźnie niższe rezultaty przepustowości, szczególnie podczas testów z 250 klientami. Porównując wyniki testów 100 i 250 klientów można zaobserwować mniejszą liczbę przetworzonych żądań gy z aplikacji korzystało 250 klientów równolegle. Wyraźne były też chwilowe spadki przepustowości. Czasy odpowiedzi również były dłuższe od aplikacji w \textsl{Go}. Analizując wyniki testowanych serwerów, na których była uruchomiona aplikacja \textsl{Java} lepsze rezultaty zaobserwowano na serwerze \textsl{Jetty}. Zarówno wyniki przepustowości oraz czasów odpowiedzi w większości przypadków testowych wykazywały przewagę nad serwerem \textsl{Tomcat}. 

Analiza wykorzystania zasobów maszyny przez poszczególne aplikacje pokazuje, że aplikacja w \textsl{Go} wymagała znacznie mniejsze zasoby od aplikacji w języku \textsl{Java}. Dzięki temu odpowiednio konfigurując środowisko można uruchomić kilka instancji aplikacji \textsl{Go} równolegle na jednej maszynie, by lepiej wykorzystać jej zasoby. Serwer \textsl{Jetty} w większości przypadków testowych, wymagał nieznacznie większych zasobów (procesora i pamięci \textsl{RAM}) od serwera \textsl{Tomcat}

Grupą testów podczas której wyniki najbardziej się wahały były testy operacji \textsl{CRUD}, które najbardziej wykorzystywały komunikację z bazą danych \textsl{MongoDB}. Podczas testów widoczne było mniejsze zużycie procesora na maszynie testowej. Najlepsze rezultaty notowano podczas testów walidacji \textsl{API} oraz obiektów \textsl{Cache}, gdzie komunikacja z bazą sprowadzała się do sprawdzenia, czy poszukiwany dokument istnieje. Walidacja \textsl{API} okazała się najbardziej wykorzystywać zasoby procesora, podczas testów aplikacji w języku \textsl{Java}. 
{'fraction_non_alphanumeric': 0.06386076989924137, 'fraction_numerical': 0.0322709444066045, 'mean_word_length': 5.636221945137157, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1526080', 'n_tokens_mistral': 18790, 'n_tokens_neox': 18805, 'n_words': 4824}