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 lock
i 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?