Krótko mówiąc: powinieneś być w stanie osiągnąć w liczbę milionów jednoczesnych aktywnych połączeń TCP i przez rozszerzenie żądania HTTP. Dzięki temu uzyskasz maksymalną wydajność, jakiej możesz oczekiwać dzięki odpowiedniej platformie i odpowiedniej konfiguracji.
Dzisiaj martwiłem się, czy IIS z ASP.NET będzie obsługiwał w kolejności 100 jednoczesnych połączeń (spójrz na moją aktualizację, oczekuj ~ 10 tys. Odpowiedzi na sekundę w starszych wersjach ASP.Net Mono). Kiedy zobaczyłem to pytanie / odpowiedzi, nie mogłem się powstrzymać od odpowiedzi, wiele odpowiedzi na to pytanie jest całkowicie błędnych.
Najlepszy przypadek
Odpowiedź na to pytanie musi dotyczyć tylko najprostszej konfiguracji serwera, aby oddzielić ją od niezliczonych zmiennych i konfiguracji możliwych do wykonania na dalszych etapach.
Rozważ więc następujący scenariusz mojej odpowiedzi:
- Brak ruchu na sesjach TCP, z wyjątkiem pakietów utrzymujących aktywność (w przeciwnym razie oczywiście potrzebowałbyś odpowiedniej przepustowości sieci i innych zasobów komputera)
- Oprogramowanie zaprojektowane do korzystania z asynchronicznych gniazd i programowania zamiast wątku sprzętowego na żądanie z puli. (tj. IIS, Node.js, Nginx ... serwer sieciowy [ale nie Apache] z aplikacjami zaprojektowanymi asynchronicznie)
- Dobra wydajność / dolarowy procesor / pamięć RAM. Dziś arbitralnie powiedzmy i7 (4 rdzenie) z 8 GB pamięci RAM.
- Dobry firewall / router.
- Brak wirtualnego limitu / zarządcy - tj. Linux somaxconn, IIS web.config ...
- Brak zależności od innego wolniejszego sprzętu - brak odczytu z dysku twardego, ponieważ byłby to najniższy wspólny mianownik i wąskie gardło, a nie sieciowe IO.
Szczegółowa odpowiedź
Synchroniczne projekty powiązane z wątkami mają zwykle najgorszą wydajność w porównaniu z implementacjami asynchronicznych operacji we / wy.
WhatsApp uzyskuje milion z ruchem na pojedynczym systemie operacyjnym o smaku Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .
I wreszcie ten, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , zawiera wiele szczegółów , badając, jak można osiągnąć nawet 10 milionów. Serwery często mają sprzętowe silniki odciążania TCP, układy ASIC zaprojektowane do tej konkretnej roli wydajniej niż procesory ogólnego przeznaczenia.
Dobre możliwości projektowania oprogramowania
Projektowanie asynchronicznych operacji we / wy będzie się różnić w zależności od systemów operacyjnych i platform programowania. Node.js został zaprojektowany z myślą o asynchroniczności . Powinieneś przynajmniej użyć Promises, a kiedy pojawi się ECMAScript 7, async
/ await
. C # / .Net ma już pełną obsługę asynchroniczną, taką jak node.js. Niezależnie od systemu operacyjnego i platformy, asynchroniczne powinny działać bardzo dobrze. Niezależnie od wybranego języka poszukaj słowa kluczowego „asynchroniczny”. Większość współczesnych języków będzie miała pewne wsparcie, nawet jeśli jest to jakiś dodatek.
Do WebFarm?
Bez względu na ograniczenia w twojej konkretnej sytuacji, tak, farma internetowa to dobre rozwiązanie do skalowania. Istnieje wiele architektur, które to umożliwiają. Jednym z nich jest równoważenie obciążenia (dostawcy hostingu mogą je oferować, ale nawet oni mają limit wraz z limitem przepustowości), ale nie preferuję tej opcji. W przypadku aplikacji jednostronicowych z długotrwałymi połączeniami wolę zamiast tego mieć otwartą listę serwerów, z których aplikacja kliencka będzie wybierać losowo podczas uruchamiania i ponownie używać przez cały okres istnienia aplikacji. Eliminuje to pojedynczy punkt awarii (moduł równoważenia obciążenia) i umożliwia skalowanie w wielu centrach danych, a tym samym znacznie większą przepustowość.
Obalamy mit - porty 64K
Aby odpowiedzieć na pytanie dotyczące „64 000”, jest to błędne przekonanie. Serwer może łączyć się z wieloma ponad 65535 klientami. Zobacz /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284
Nawiasem mówiąc, Http.sys w systemie Windows umożliwia wielu aplikacjom współużytkowanie tego samego portu serwera w ramach schematu adresu URL HTTP. Każdy z nich rejestruje oddzielne powiązanie domeny, ale ostatecznie istnieje jedna aplikacja serwerowa, która przekazuje żądania do odpowiednich aplikacji.
Aktualizacja 2019-05-30
Oto aktualne porównanie najszybszych bibliotek HTTP - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- Data testu: 2018-06-06
- Używany sprzęt: Dell R440 Xeon Gold + 10 GbE
- Lider ma ~ 7 mln odpowiedzi w postaci zwykłego tekstu na sekundę (odpowiedzi, a nie połączenia)
- Drugi Fasthttp dla golanga reklamuje 1,5 mln równoczesnych połączeń - patrz https://github.com/valyala/fasthttp
- Wiodącymi językami są Rust, Go, C ++, Java, C, a nawet C # w rankingu 11 (6,9 mln na sekundę). Scala i Clojure zajmują niższe pozycje. Python zajmuje 29 miejsce z szybkością 2,7 mln na sekundę.
- Na dole listy notuję laravel i cakephp, rails, aspnet-mono-ngx, symfony, zend. Wszystko poniżej 10 tys. Na sekundę. Uwaga, większość tych frameworków jest zbudowana dla stron dynamicznych i jest dość stara, mogą istnieć nowsze warianty, które znajdują się wyżej na liście.
- Pamiętaj, że jest to zwykły tekst HTTP, a nie specjalizacja Websocket: wiele osób przyjeżdżających tutaj będzie prawdopodobnie zainteresowanych równoczesnymi połączeniami dla protokołu Websocket.