Jakiś czas temu były informacje że stos ułożony pod benchmark, z whardkodowaną odpowiedzią, robił 7mln żądań na sekundę. Przy takiej wydajności na poziomie żądanie-odpowiedź, można przyjąć że to nie WebAPI/NET będzie wąskim gardłem tylko to co się w stosie dzieje niżej, na danych.
ilu klientów na raz jest w stanie obsłużyć aplikacja typu CRUD hostowaną na serwerze
Nie stawia się tak pytań "ilu klientów", tylko "ile żądań". Przy przepustowości n żądań na sekundę, liczba użytkowników których się obsługuje jest dużo wyższa, bo statystyczny użytkownik CRUDowych aplikacji można przyjąć że nie generuje żądania co sekundę (tylko mniej).
od wydajności/mocy serwera
i od tego co się faktycznie dzieje w ramach żądań. dwie aplikacje: taka która ma per żądanie whardkodowane "return hello world" i taka która per żądanie faktoryzuje 100 cyfrową liczbę, będą miały skrajnie różne przepustowości
poza tym w jakich jednostkach określa się taki ruch. Ilość zapytań na minutę, a może godzinę lub jeszcze jakimiś innymi jednostkami posługujecie się w pracy
przepustowość określa się w liczbie żądań na sekundę. ale Klient w zamówieniu napisze być może inaczej - napisze że aplikacja powinna gwarantować czas odpowiedzi na poziomie X (np. 1 sekundy). Takie zapisy staramy się zawsze tłumaczyć że są problematyczne, bo bez określenia nasilenia ruchu nie ma do czego tego odnieść. Czyli ilu aplikacja ma użytkowników.
Jak Klient powie np. 3000, to przy założeniu klikania przez użytkownika (nawet z zapasem) raz na 5 sekund, oznacza to przepustowość 500-600 żądań na sekundę. To mało. I tak zwykle stawia się co najmniej dwa serwery (żeby był chociaż jakiś zalążek architektury failover), 600 żądań na dwa (lub więcej) serwerów to raczej mało. Jak Klient powie np. 300000 to jest kwestia szacowania co jest wtedy wąskim gardłem - jeśli serwery aplikacyjne to je można klastrować, jeśli baza to trudniej, bo trzeba inaczej stos ułożyć.
czy klient zlecający do SH napisanie jakiejś apki określa wam to jaki ruch musi być obsłużony?
jeśli nie określa to trzeba się tego domagać, architektura jest pochodną wymagań, a brak wymagań z grupy "performance" oznacza czynnik nieprzewidziany, czyli ryzyko
co się dzieje z aplikacją gdy jest nadmiernie obciążona. Przestaje całkowicie działać czy tylko zwalnia?
pojedynczy serwer - najczęściej jest tak skonfigurowany (domyślnie) że lecą z niego 500
czy WebApi bez systemu kolejkowego w sytuacji nadmiernego obciążenia "gubi" część wysłanych żądań
WebApi z systemem kolejkowym w tle, jak przyjmie za dużo żądań to też część "zgubi".
co się robi jeśli wiadomo że aplikacja będzie musiała obsługiwać wile żądań
jak pojedyncza serwerownia nie wyrabia, to można mieć więcej niż jedną i na poziomie DNSa rozprowadzać użytkowników równomiernie na wiele fizycznych lokalizacji. Potem jest już tylko kwestia tego ile jest tych fizycznych lokalizacji ("DNS Round-robin") i nie ma takiego poziomu ruchu którego nie da się dźwigać, jest tylko kwestia kosztów. Duzi dźwigają po kilka miliardów i sobie radzą jakoś.
Jaka ilość zapytań możliwa do obsłużenia przez małe api, jest obecnie uznawana za taki standard
Zakładając bardzo upraszczająco, prosta baza relacyjna, proste CRUDy, WebAPI i żadnych "spowalniaczy", to można przyjąć że kilka tysięcy żądań na sekundę to jest oczekiwana przepustowość.
