Każdy serwer internetowy może obsługiwać wiele żądań w tym samym czasie. Jako, że interpreter python faktycznie ma ograniczenie GIL, jak implementowana jest współbieżność?W jaki sposób serwer WWW Pythona pokonuje GIL
Czy używają wielu procesów i używają IPC do udostępniania stanu?
Jak zwykle. Serwery WWW są w większości obsługiwane przez I/O, a GIL jest wyzwalany podczas operacji we/wy. Tak więc wątkowanie jest używane bez specjalnych udogodnień, lub używa się pętli zdarzeń (takich jak Twisted).
Nie mówię o żądaniu oczekiwania/otrzymaniu. Mówię o ich obsłudze. Na przykład, jeśli otrzymam żądanie, być może będę musiał wykonać pewne przetwarzanie, na przykład sprawdzanie różnych żądań POST lub GET, które zazwyczaj są zapisywane jako kod Pythona. W jaki sposób interpreter Pythona będzie wykonywać te bloki kodu jednocześnie, ponieważ ma ograniczenie GIL. –
To po prostu nieprawda. Nie wszystkie obciążenia są związane z IO. Całkowicie powszechne jest wyświetlanie serwerów WWW z maksymalnie obciążonymi procesorami. To zależy od uruchamianej aplikacji. – usr
Zwykle masz wielu pracowników (tj. Gunicorn), z których każdy jest wysyłany z niezależnymi wnioskami. Cała reszta (współbieżność) jest obsługiwana przez bazę danych, więc jest pobierana od Ciebie.
Nie trzeba IPC, wystarczy „jednego źródła prawdy”, który będzie RDBMS, serwer cache (Redis, memcached) itd
Przede wszystkim, wnioski mogą być obsługiwane niezależnie. Jednak serwery chcą jednocześnie obsługiwać je w celu zachowania liczby żądań, które można obsłużyć na czas maksymalnie.
Implementacja tej koncepcji współbieżności zależy od serwera WWW.
Niektóre implementacje mogą mieć ustaloną liczbę wątków lub procesów obsługi żądań. Jeśli wszystkie są w użyciu, dodatkowe żądania muszą poczekać, aż zostaną obsłużone.
Inną możliwością jest zrobienie procesu lub wątku dla każdego żądania. Rozgałęzienie procesu dla każdego żądania prowadzi do absurdalnego obciążenia pamięci i cpu. Tarła lekkich nici jest lepsza. Dzięki temu możesz obsłużyć setki klientów na sekundę. Jednak wątki również zwiększają koszty zarządzania, objawiając się dużą ilością pamięci i zużyciem procesora.
Do obsługi tysięcy klientów na sekundę architektura sterowana zdarzeniami oparta na asynchronicznych programach typu coroutines jest najnowocześniejszym rozwiązaniem. Umożliwia serwerowi obsługę klientów w wysokim tempie, bez pojawiania się milionów wątków. Na stronie Wikipedia page of the so-called C10k problem znajduje się lista serwerów internetowych. Wśród nich wielu korzysta z tej architektury.
Coroutines są również dostępne w języku Python. Spójrz na http://www.gevent.org/. Dlatego aplikacja Python WSGI oparta na np. uWSGI + gevent jest niezwykle wydajnym rozwiązaniem.
"Rozrastanie się procesu dla każdego żądania prowadzi do absurdalnej pamięci i obciążenia procesora." Jest to całkowicie zależne od systemu operacyjnego. –
@ Ignacio Vaazquez-Abrams: dla którego OS nie jest to prawdą ("absurd" miał na myśli w porównaniu z napowietrznymi wątkami lub coroutinami)? –
Nie chodzi o to, że nie jest to prawda, ale że dokładna definicja "absurdu" jest różna; Windows to duża, parująca kupa błogosławionych ekskrementów, jeśli chodzi o rozpoczynanie nowych procesów, ale * nices są w porównaniu do nich nieco lżejsze. –
Jakie udostępnianie stanu? Głównym celem żądań internetowych jest to, że każdy jest niezależny, nie ma wspólnego stanu. –