Czy jest jakiś test porównawczy lub porównanie, które jest szybsze: umieść nginx przed węzłem i pozwól mu bezpośrednio obsługiwać pliki statyczne lub użyj tylko węzła i obsługuj pliki statyczne za jego pomocą?
Rozwiązanie nginx wydaje się być dla mnie łatwiejsze w zarządzaniu, jakieś myśli?
Odpowiedzi:
Muszę się nie zgodzić z odpowiedziami tutaj. Podczas gdy Node poradzi sobie dobrze, nginx z pewnością będzie szybszy, gdy zostanie poprawnie skonfigurowany. nginx jest efektywnie zaimplementowany w języku C zgodnie z podobnym wzorcem (powrót do połączenia tylko w razie potrzeby) z niewielkim zużyciem pamięci. Co więcej, obsługuje wywołanie systemowe sendfile, aby obsłużyć te pliki, które są tak szybkie, jak to tylko możliwe, podczas udostępniania plików, ponieważ to samo jądro systemu operacyjnego wykonuje zadanie.
Do tej pory nginx stał się de facto standardem jako serwer frontendowy. Możesz go użyć do obsługi plików statycznych, gzip, SSL, a nawet później do równoważenia obciążenia.
PS: Zakłada się, że pliki są naprawdę „statyczne”, ponieważ znajdują się na dysku w momencie żądania.
sendfile- ale wygląda na to, że musisz napisać jakiś kod, patrz np. blog.std.in/2010/09/09/using-sendfile-with-nodejs
Zrobiłem szybko, ab -n 10000 -c 100aby obsłużyć statyczny bajt 1406 favicon.ico, porównując nginx, Express.js (statyczne oprogramowanie pośredniczące) i Express.js w klastrze. Mam nadzieję że to pomoże:
Niestety nie mogę przetestować 1000 lub nawet 10000 jednoczesnych żądań, ponieważ nginx na moim komputerze zacznie generować błędy.
EDYCJA : zgodnie z sugestią artvolka, oto wyniki klastra + staticoprogramowanie pośredniczące (wolniejsze):
staticoprogramowanie pośredniczące do buforowania zrobi w produkcji.
Mam inną interpretację wykresów @ gremo. Wydaje mi się, że zarówno skala węzła, jak i nginx przy tej samej liczbie żądań (między 9-10 tys.). Jasne, opóźnienie odpowiedzi dla nginx jest niższe o stałe 20 ms, ale nie sądzę, aby użytkownicy koniecznie dostrzegli tę różnicę (jeśli twoja aplikacja jest dobrze zbudowana). Biorąc pod uwagę stałą liczbę maszyn, zajęłoby to dość duże obciążenie, zanim przekonwertowałbym maszynę węzła na nginx, biorąc pod uwagę, że węzeł jest miejscem, w którym większość obciążenia wystąpi w pierwszej kolejności. Jedynym przeciwwagą jest to, że już przeznaczasz maszynę dla nginx do równoważenia obciążenia. Jeśli tak jest, równie dobrze możesz sprawić, że będzie on obsługiwał również zawartość statyczną.
Tak czy inaczej, skonfigurowałbym Nginx, aby buforował pliki statyczne ... zobaczysz tam OGROMNĄ różnicę. Następnie, niezależnie od tego, czy obsługujesz je z węzła, czy nie, w zasadzie uzyskujesz taką samą wydajność i takie samo odciążenie w aplikacji węzła.
Osobiście nie podoba mi się pomysł, że mój frontend Nginx obsługuje statyczne zasoby w większości przypadków
1) Projekt musi teraz znajdować się na tym samym komputerze - lub musi zostać podzielony na zasoby (na komputerze nginx) i aplikację internetową (na wielu komputerach w celu skalowania)
2) Konfiguracja Nginx musi teraz utrzymywać lokalizacje ścieżek dla statycznych zasobów / przeładowania, gdy się zmienią.
To trudne pytanie. Jeśli napisałeś naprawdę lekki serwer węzłów, który obsługuje tylko pliki statyczne, najprawdopodobniej działałby lepiej niż nginx, ale nie jest to takie proste. ( Oto "test porównawczy" porównujący serwer plików nodejs i lighttpd - który jest podobny pod względem wydajności do ngingx podczas obsługi plików statycznych).
Wydajność w zakresie obsługi plików statycznych często sprowadza się do czegoś więcej niż tylko serwera WWW wykonującego pracę. Jeśli chcesz uzyskać najwyższą możliwą wydajność, będziesz używać CDN do obsługi plików, aby zmniejszyć opóźnienia dla użytkowników końcowych i skorzystać z buforowania na krawędzi.
Jeśli się tym nie martwisz, node może obsługiwać pliki statyczne w większości sytuacji. Węzeł nadaje się do kodu asynchronicznego, na którym również polega, ponieważ jest jednowątkowy, a każde blokujące operacje wejścia / wyjścia mogą zablokować cały proces i obniżyć wydajność aplikacji. Najprawdopodobniej piszesz swój kod w sposób nieblokujący, ale jeśli robisz coś synchronicznie, możesz spowodować blokowanie, które zmniejszyłoby szybkość obsługi plików statycznych przez innych klientów. Łatwym rozwiązaniem jest nie pisanie kodu blokującego, ale czasami nie jest to możliwe lub nie zawsze można go wymusić.
Jestem pewien, że czysto node.js może przewyższać nginx pod wieloma względami.
Wszystko powiedziawszy, muszę pozostać NginX ma wbudowaną pamięć podręczną, podczas gdy node.js nie jest instalowany fabrycznie (MUSISZ ZBUDOWAĆ WŁASNĄ CACHE PLIKÓW). Niestandardowa pamięć podręczna plików przewyższa nginx i każdy inny serwer na rynku, ponieważ jest bardzo prosta.
Również Nginx działa na wielu rdzeniach. Aby w pełni wykorzystać potencjał Node, musisz połączyć serwery węzłów w klastry. Jeśli chcesz wiedzieć, jak to zrobić, proszę o godz.
Trzeba głębiej kopać, aby osiągnąć nirwanę wydajności z node, to jedyny problem. Raz zrobione piekło tak ... to bije Nginx.