Jaki ruch jest w stanie obsłużyć WebApi

co się robi jeśli wiadomo że aplikacja będzie musiała obsługiwać wile żądań. Hostuje na chmurze i wprowadza podział na mikro serwisy?

Nie jestem C#, ale jako że padło magiczne słowo "mikro serwisy" to się wypowiem.

I tak i nie. W zasadzie to ważne jest żeby aplikacja była bezstanowa, i wtedy można ją zdeplojować w chmurze w wielu instancjach. A cały stan jest albo u klienta, albo w bazie. W ten sposób przesuwa się problem o ileśtam requestów. Następny będzie jak baza przestaje dawać radę a klastrowanie bazy do już nie jest taka prosta rzecz. Często może skończyć się to przepisaniem prostego Postgresa (czy to tam w .Necie się używa do zapisu danych) na jakies bardziej skomplikowane NoSQL jak Cassandra

Michał Jasiński napisał(a):

• 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?

Liczb z dziedziny wydajnosciowej wymienił by pewnie z 10 albo 20. Max response tive, average, jakieś mediany, throughput i wiele inncyh. Co więcej, każdy z nich niewłaściwie / bez zrozumienia użyty będzie zakłamaniem. Ferrari jest szybsze od TiRa, ale to TiR przewiezie więcej sztuk towaru na km w jednostce czasu.
Pytasz pod jakieś szkolne wypracowanie, czy kandydujesz na specjalsitę

NIE DA SIĘ w popularnym poście wyłożyć obszernej dziedziny wiedzy.

• co się dzieje z aplikacją gdy jest nadmiernie obciążona. Przestaje całkowicie działać czy tylko zwalnia?

Zależy w jakim sensie przeciążona, i na ile do tego przygotowana. Od zabicia przez SO / MV (wzrost RAM ponad limit - brak obsługi wyjatku wewn.)
przez jasną odmowę następnych (dość ładne zachowanie, wcale nie łatwe do wykonania), niejasne zawiśniecie requestów "nie wiadomo co".

• czy WebApi bez systemu kolejkowego w sytuacji nadmiernego obciążenia "gubi" część wysłanych żądań?

Kolejkowanie WebAPI ... oj, to by miało wiele negatywów (starając się zrobić jakiś plus)

A ile żądani jest w stanie obsłużyć jakiś zwykły, budżetowy serwer. Jakie to są wartości ?

Michał Jasiński napisał(a):

A ile żądani jest w stanie obsłużyć jakiś zwykły, budżetowy serwer. Jakie to są wartości ?

A co "jedna sztuka" robi? Zwraca stały string, czy wykonuje zróżnicowane kwerendy z bazą ? Core Duo 4GB, dyski mechaniczne, czy 24 rdzenie i 64 GB, SSD ?
Rozumiesz, ze nie da się odpowiedzieć ?

AnyKtokolwiek napisał(a):

Michał Jasiński napisał(a):

A ile żądani jest w stanie obsłużyć jakiś zwykły, budżetowy serwer. Jakie to są wartości ?

A co "jedna sztuka" robi? Zwraca stały string, czy wykonuje zróżnicowane kwerendy z bazą ? Core Duo 4GB, dyski mechaniczne, czy 24 rdzenie i 64 GB, SSD ?
Rozumiesz, ze nie da się odpowiedzieć ?

W porządku, rozumiem. Niestety ten temat jest dla mnie całkowicie obcy, a chciał bym mieć jakiś punkt odniesienie co do wartości.
Może więc zapytam nieco inaczej. Jaka ilość zapytań możliwa do obsłużenia przez małe api, jest obecnie uznawana za taki standard?

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ść.

Wiktor Zychla napisał(a):

...

Dziękuje serdeczne. Świetne wyjaśnienie :)