Odpowiedź womble jest niesamowita, choć trochę trudna do zrozumienia i ubiegania się o niedoświadczonego. Chciałbym podać kilka danych empirycznych oraz porównanie „prostych treści” z „e-commerce”.
Nie ma zbyt wiele materiału na temat ustawiania różnych przypadków użycia w związku z ich odpowiednią konfiguracją mod_wsgi, więc mam nadzieję, że można tu użyć trochę prozy.
A) Witryny CMS i mikrostrony
Prowadzimy kilka witryn dla klientów, większość z nich to głównie witryny z treściami lub mikro witryny z systemem Django CMS, niektóre niestandardowe formularze, a czasem Selery do zaplanowanych zadań w tle. Witryny te nie są głodne zasobów, niektóre z nich działają równolegle na jednym 4-rdzeniowym procesorze Intel Xeon z 32 GB pamięci RAM. Oto konfiguracja, której używamy dla każdego z tego rodzaju witryn:
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
Mówię o około 40 witrynach na jednym serwerze, w większości z witryną pomostową działającą w trybie gotowości. Dzięki 2 procesom (domyślnie 15 wątków) witryny są zamożne, aczkolwiek ograniczone możliwości alokacji zasobów serwera. Dlaczego ta konfiguracja jest wystarczająca, można uzasadnić prostym charakterem aplikacji (CMS): nigdy nie oczekuje się, że wykonanie żądania zajmie więcej niż kilka milisekund. Apache zawsze pozostanie zrelaksowany, podobnie jak obciążenie procesora.
B) Witryny e-commerce
Bardziej złożone witryny, które wykonujemy, charakteryzują się nadal niedrogimi operacjami lokalnymi pod względem obliczeniowym, ale zewnętrznymi zależnościami (np. Serwisami internetowymi dostarczającymi dane do rezerwacji), które są drogie pod względem czasu transakcji. Operacje z zewnętrznymi żądaniami zajmują wątki przez znacznie dłuższy czas, więc potrzebujesz więcej wątków, aby obsłużyć tę samą liczbę użytkowników (w porównaniu do prostej strony CMS z góry). Co gorsza, wątki są czasami blokowane, gdy usługa zewnętrzna nie może natychmiast odpowiedzieć na żądanie, czasami przez kilka sekund. Może to prowadzić do nieprzyjemnego efektu ubocznego polegającego na tym, że wątki umieszczające żądania w tej samej kolejce usług w górę, dopóki wszystkie dostępne wątki mod_wsgi nie zostaną zużyte i zablokowane.
W przypadku tych scenariuszy próbowaliśmy używać 6procesów, nie widząc dużej różnicy, i ostatecznie 12dostrzegliśmy nieporównywalny wzrost wydajności i stabilności operacyjnej:
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
Niektóre proste testy obciążenia z 150 i 250 równoległymi użytkownikami są łatwo obsługiwane przez witrynę pozostającą dobrze reagującą (podczas gdy z 2procesami strona nie nadaje się do obsługi 50 użytkowników równolegle). Dwurdzeniowy 6-rdzeniowy procesor Intel Xeon z 32 GB pamięci RAM działa znacznie poniżej 25% wykorzystania procesora pod tym obciążeniem, zużycie pamięci RAM prawie pozostaje na stałym poziomie poniżej 25%. Pamiętaj, że używamy tutaj dedykowanej maszyny tylko dla jednej witryny, więc nie będziemy kraść zasobów potrzebnych innym stronom.
Wniosek
Korzystanie z większej liczby procesów jest kompromisem między umożliwieniem Apache korzystania z dostępnych zasobów systemowych lub nie. Jeśli chcesz utrzymać stabilny system serwera (nie stronę internetową!) W warunkach „ataku”, utrzymuj niską liczbę. Jeśli chcesz, aby Apache pomagał ci w korzystaniu z zasobów systemowych (procesora, pamięci RAM) w razie potrzeby, wybierz wyższą liczbę. To, jak wysoko możesz przejść, oblicza się nieco tak, jak opisano w zaakceptowanej odpowiedzi powyżej, i jest ostatecznie ograniczone dostępną mocą procesora i pamięci RAM.
(PS: Trzymam sekcję ConfigurationDirectives wiki projektu modwsgi pod moją poduszką do czytania w tle podobnego do Apache. Pamiętaj również, aby zrozumieć i monitorować otwarte połączenia twojego serwera Apache .)