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

Odpowiedz Nowy wątek
2019-07-28 00:49
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?

edytowany 1x, ostatnio: cerrato, 2019-07-28 01:42

Pozostało 580 znaków

2019-07-28 10:59
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.

Pozostało 580 znaków

2019-07-28 23:56
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 :)

Pozostało 580 znaków

2019-08-08 17:46
1

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


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


Zwolnij testerów, niech testują użytkownicy :) - ralf 2019-08-09 11:11
@ralf: Co ma piernik do wiatraka? Testy odpalisz sobie lokalnie, performance już nie. Na twoim Ryzen 9 będzie działać pięknie, a wgrasz na klaster dockerów i się będzie ciąć. Testy wydajnościowe zwykle częściej kłamią niż coś testują. Na prod masz inny procesor, inny dysk, inną sieć, cgroupy inny jvm etc. Nie odwzorujesz tego w teście. - nie100sowny 2019-08-09 12:29
@nie100sowny rozumiem, że niektórzy wolą robić tylko zadania łatwe a nie trudne. Testów tez nie odpalasz tylko lokalnie ale są kolejne środowiska integracyjne. Tak samo są środowiska do testów wydajnościowych skalowane albo identyczne. Prezentujesz podejście niech klienci powiedzą mi, że coś nie działa i jeszcze innych do tego namawiasz. - ralf 2019-08-09 15:20

Pozostało 580 znaków

2019-08-09 15:28
2

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


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 1x, ostatnio: LukeJL, 2019-08-09 15:29

Pozostało 580 znaków

2019-08-09 16:15
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-08-09 17:13
0

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


Nie polecam jmetera - Charles_Ray 2019-08-09 21:07

Pozostało 580 znaków

2019-08-09 17:46
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)

"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


edytowany 1x, ostatnio: nie100sowny, 2019-08-09 17:47

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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