# Wstęp
Szybkośc ładowania się stron w aplikacji webowej może mieć wpływ na zyski [1]. Dodatkowo mniejsze wykorzystanie zasobów może wpływać na zmniejszenie kosztów utrzymania (no tu chyba cytatu nie trzeba). W tej publikacji sugerujemy, że wybierając odpowiedni runtime możemy poprawić te dwie metryki bez ingerencji w aplikację.

P1 Cel: Optymalizacja programowego środowiska wykonawczego aplikacji - bez kubernetesa
P2 Cel: Optymalizacja środowiska wykonawczego dla z kubernetesem, HPA
P3 Cel: Sam scoring

I do tego dane.

## Poprzednie prace
W literaturze łatwo znaleźć porównania wydajnościowe wielu frameworków [2], [3], [4], [7]. [2], [3], [4] skupiają się na frameworkach PHP. [7] jest ogólnym zbiorem danych. Zmiana frameworka jest kosztowna i wymaga ingerencji w kod aplikacji bądź zupełnego przepisania. Brak natomiast źródeł, które sprawdzałyby wydajność aplikacji z wykorzystaniem różnych środowisk uruchomieniowych. Dla PHP będą to: Apache (mod-php), FPM, RoadRunner, PHP-PM, Swoole, FrankenPHP. Dla pythona można by sprawdzić np. uvicorna, gunicorna, pypy oraz cpythona w macierzy. Java nie mam pojęcia. Dotnet Kestrel vs http.sys.

Robimy na podstawie PHP, ale gdzieś musi być uogólnienie i pokazać, że działa też w innych scenariuszach.

Tutaj ktoś opisywał symulacyjne testowanie web serwerów: [5], możemy coś zaczerpnąć z metodyki, ale jest stare i wymaga dostosowania do dzisiejszych realiów (w tym protokołów). Ktoś już zrobił rewizję [6] ale pomija w nich wykorzystanie zasobów sprzętowych + metrykę błędów. Żadna ze znalezionych publikacji nie opiera się na realnych aplikacjach.

# Metodologia
AK ma przygotować jakiś scoring, który uwzględni wydajność aplikacji, stabilność oraz wykorzystanie sprzętu.

## Zbierane metryki
- cpu
- mem
- request time
- error rate
- liczba aktualnych uzytkownikow

## Score
- quality - cas obslgui (im szybciej i bezbledniej tym lepiej -> błąd - max)
- load - na podstawie obciazenia cpu i ramu
- apdex score [8]
- Współczynniki $C_f$ i $M_f$ bierzemy na podstawie kosztu danego zasobu z np. AWS albo skądkolwiek
- Współczynnik chaosu - do wyznaczenia jak wpływają inne aplikacje na wyniki

## Rodzaje zadań
1. Zadania proste - czas inicjalizacji >> czas przetwarzania
2. zadania trudne - czas przetwarzania >> czas inicjalizacji

Zdaje się, ze większość to zadania proste (wymagane cytowanie). Dodatkowo można by uwzględnić wpływ cache na ten proplem (zadanie nie jest trudne, jeżeli znamy jego wynik).

## Scenariusze i środowisko testowe.
Bierzemy znaną krzywą ruchu i odpalamy na aplikacji. Jak będzie nam sie chciało to robimy A/B na moście, gdzie A to fpm a B to road runner (z wyników wstępnych wychodzi, że najlepszy). Odpalamy na kubernetesie, na izolowanych węzłach działających na znanych maszynach.

### PHP:
- symfony-demo-apache (klasyczny)
- symfony-demo-builtin (ciekawostka) - skalowanie podami
- symfony-demo-fpm (klasyczny) - statyczny vs dynamiczny
- symfony-demo-php-pm (long-run)
- symfony-demo-rr (long-run)
- symfony-demo-swoole (long-run) - skalowanie podami

### Baseline:
- nginx (popularnosc uzycia ze wzgledu na ankiety - podaj biblio)
- 2 GiB RAM + ilosc workerow ktore to zezra (+/-) + brak errorow
- 80pp
- konfiguracja od ktorej porownujemy
- testy
- wzrost liniowy uzytkownikow (czas + przyrost)
- dluzsze obciazenie przy stalej liczbie userow (prog stabilnosci nginxa)
- bardzo dlugie obciazenie na podstawie krzywej obciazenia mojejpg

# Wyniki
Z naszych wcześniejszych testów wyszło, że dla zadań prostych oszczędność czasu bywa nawet 10x, zużycie pamięci też bywa znacznie mniejsze w stosunku do np. apache, a podobne w stosunku do fpma. Wychodziło też, że może i nie zużywamy mniej zasobów, ale lepiej je wykorzystujemy bo średnie obciążenie procesora wynosi 100% więc nie marnujemy zasobów.

- apache wydajniejszy od nginxa (nginx wchodzil na errory), ale zzera ram
- builtiny zeskolawne moga dzialac najszybciej
- swoole by dzialal lepiej przy aplikacji async (wymaga poważnych zmian w aplikacji)
- dla aplikacji mocno CPU roznice bylyby mniejsze

## Pytania
- czy lepiej skalowac pody poziomo czy pionowo
- warunki nielabo i labo (dedykowane i zywa chmura) + wspolczynnik chaosu
- wplyw na wykorzystanie zasobow
- potencjalny wplyw na conversion-rate (im szybciej tym lepiej) - biblio belkot
- wykorzystanie ramu (obliczenia vs rzeczywistosc)

[1]: https://link.springer.com/chapter/10.1007/978-3-319-67220-5_31
[2]: https://www.diva-portal.org/smash/get/diva2:846121/FULLTEXT01.pdf
[3]: https://pdf.sciencedirectassets.com/306234/1-s2.0-S2351978919X00074/1-s2.0-S2351978919303312/main.pdf
[4]: https://ieeexplore.ieee.org/document/8248546
[5]: https://ieeexplore.ieee.org/abstract/document/953356
[6]: https://ieeexplore.ieee.org/document/6784980
[7]: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r22
[8]: https://www.apdex.org/docs/Defining_The_Application_Performance_Index.pdf