Jak testować wydajność przed wypuszczeniem produktu na większej liczbie ludzi?

0

Załóżmy, że chciałbym upublicznić tę swoją gierkę webową, którą w wolnym czasie dłubię. Jeszcze nie w najbliższej przyszłości, ale kiedyś może...

Gdybym wstawił to na np. Newgrounds, myślę, że w pierwszych dniach trochę ludzi by było. Taki jest, jak sądzę, cykl życia produktów tam wrzucanych: Jeśli przejdą pierwsze (niezbyt wygórowane) kontrole jakości, to przez jakiś czas liczony w granicach między dniami a miesiącami (zależnie, czy chwyci), uwaga użytkowników strony kieruje się na nowo wrzuconą grę. Potem gra albo zyskuje szansę trwalszego wybicia (podstawę do wrzucenia jej do bardziej prestiżowych stron i oczekiwania sukcesu tamże i/lub gronko fanów oczekujących sequeli) albo schodzi w niebyt.

Jako, że ta gra z natury jest wieloosobową grą z centralnym serwerem... Wypadałoby zapewnić, by gra przynajmniej wydajnościowo wytrzymała pierwszych kilka dni (by przynajmniej powód odejścia do niebytu był bardziej merytoryczny, niż "gra nie działa" ;P)

Od półtora roku próbuję zrobić wreszcie działający prototyp... z naciskiem na DZIAŁAJĄCY PROTOTYP, implementujący minimum zaplanowanej funkcjonalności. Nie dbam zbytnio o jakość kodu, chociaż staram się zbierać opinie, jak to powinno wyglądać, kiedy/jeśli przyjdzie czas na przepisywanie tego. Z tej samej też przyczyny wziąłem sobie do serca maksymę, iż "premature optimization is the root of all evil". Jest kilka miejsc, gdzie widzę, że jest nieefektywnnie: np. złożoność jest niepotrzebnie kwadratowa, podczas gdy mogłaby być istotnie mniejsza. Jednak na ile to ma znaczenie w praktyce, nie wiem. (Zdaje mi się, choć nie wiem jak to sprawdzić, że tablica, po której jest niepotrzebnie kwadratowa złożoność jest na tyle mała, że MOŻE nie mieć to znaczenia). W jednym miejscu niepotrzebnie zakładane są bezwzględne locki tam, gdzie należałoby pdobnie użyć blokad w stylu czytelników i pisarzy albo w ogóle blokady olać uznając, że p-dobieństwo, że ktoś otrzyma niespójne dane jest zbyt znikome. Prawdopodobnie także jest jeszcze trochę miejsc, gdzie są problemy wydajnościowe, o których nie wiem. Myślałem sobie jednak, że nie będę się tym zajmował na razie: wydajność jest OK dla celów testowania tego na moim własnym laptopie i udawaniu, że jestem jakimiś dwoma userami - jeśli userów pojawi się więcej, to będę te problemy rozwiązywał na bieżąco. Tym bardziej, że wtedy już będę mógł mieć jakieś dane, gdzie wydajność siada i nad którymi partiami kodu należy pracować.

No ale przecież to tak nie działa. Jeśli chcę opublikować grę MUSZĘ być gotowy na burst userów w pierwszych kilku dniach.

No i stąd pytanie, jak się na to przygotować?

Mam serwer pisany w ASP .NET Core, chciałbym wiedzieć jak można oszacować, ilu userów na raz taki serwer może wytrzymać bez sprawdzania tego eksperymentalnie i dowiadywania się, że "mniej niż należało" kiedy jest już za późno?

W bardziej skomplikowanych projektach należy mieć wyplujkę profilera przed myśleniem o wydajności - ale jak? Chcę wiedzieć, jak serwer sie zachowa pod wieloma użytkownikami, więc pod wieloma należałoby go profilować, ale z drugiej strony profiler spowalnia (z mojego doświadczenia) naprawdę bardzo (o rzędy wielkości nawet! - chociaż ostatnio miałem z tym problemy dobre parę lat temu gdy tłukłem się z zadaniem zaliczeniowym na studia, moze profilery zrobiły postępy od tego czasu, nie wiem), więc nie można profilować pod wieloma userami.

Jak się w ogólności przygotowuje tego typu projekty przed puszczeniem ich w świat i jak się upewnia, że w świat puścić je można bez ryzyka, że przestaną działać pierszego dnia?

0

Nieraz nawet bardzo duże firmy robią Beta Access by testować tego typu rzeczy. Myślę, że najprościej jest napisać symulator gracza (wywoływanie podobnych akcji sieciowych co gracz), a później odpalić równolegle 1000 symulacji i patrzeć na czasy odpowiedzi serwera.

0

Masz najprostszy przypadek czyli system jest nowy. Możesz testy wydajnościowe przeprowadzić na docelowym środowisku, inaczej musiałbyś postawić nowe. Zakładasz sobie na początek ile chcesz użytkowników, co będą robić i piszesz dla nich scenariusze testowe. Wypełniasz system danymi i odpalasz równoległe testy. Do tego możesz dodać przyrost użytkowników w czasie.
To co będziesz sprawdzał to czasy odpowiedzi, ilość równoległych sesji, użycie cpu, ram itp. jak masz serwery albo rachunek jak masz clouda :)

2

Testy wydajnościowe są drogie i trudne. Nie trać czasu. Znacznie lepszym pomysłem jest dobry monitoring.
Monitoruj czasy HTTP, zapytań do bazy, ewentualnie wywołania ważniejszych metod. Wówczas masz dane bezpośrednio z produkcji.
Polecam narzędzia typu: https://www.guru99.com/new-relic-alternative.html

3

A nie możesz najpierw produkt wypuścić testowo w wąskim gronie? (i np. dawać jakieś zaproszenia). I samemu decydować jak wiele ludzi może grać naraz? (dopóki się nie upewnisz, że dana liczba osób nie obciąża zbytnio serwera)

Jeśli chcę opublikować grę MUSZĘ być gotowy na burst userów w pierwszych kilku dniach.

optymista xD

2

Trochę się zgodzę z @nie100sowny: sztuczne testy wydajnościowe przed wypuszczeniem publicznie nie mają sensu, bo jest ogromna szansa, że będą przekłamane.

Ale nie zgadzam się z tym, że to w ogólności strata czasu, bo sens mają ogromny. Jeśli są zawsze odpalane na takim samym środowisku, to pozwalają stwierdzić jakiego względnego spadku/wzrostu wydajności możemy się spodziewać po nowej wersji, a to już dość istotna informacja.

0

Jak głosi znane powiedzenie, "ruch produkcyjny najszybciej wygenerujesz na produkcji" ;) Pobaw się https://jmeter.apache.org/ - może się przyda.

1

Feedback ponad wszystko. Metryki wydajności są potrzebne, testy wydajności na samym końcu.

Wydasz kasę na środowiska, stracisz czas na napisanie testów i rozwiązanie wszystkich podchwytliwych tematów. Będziesz szczęśliwy, że masz hiper szybką aplikację, a po wgraniu okaże się, że coś się rozkonfigurowało w konfiguracji i muli - jak nie masz metryk to się nie dowiesz. Testy wydajnościowe to napiszesz jak gra zacznie przynosić 100000$ zysku miesięcznie.

W skrócie testy wydajnościowe piszesz gdy:

  • najważniejsze funkcje systemu są gotowe,
  • w kodzie mniej więcej posprzątane i dobra architektura,
  • wszystko zautomatyzowane CD/CI zrobione
  • monitoring / logowanie zrobione
  • dobrze napisane testy funkcjonalności z 90% pokryciem (pokrycie to dziadowska miara)

1 użytkowników online, w tym zalogowanych: 0, gości: 1