Dlaczego Nginx jest tak szybki?


31

W jaki sposób strona taka jak rambler dostarcza tak dynamiczną zawartość? Nawet szybciej niż Yahoo (który ma serwer w moim kraju - SE Asia; rambler nie).

Czy jest to zdolność wyłącznie Nginx? Gdzie powinienem szukać informacji o takich możliwościach?

Prawie nowicjusz tutaj, uważam, że serverfault.com, jeśli jest obsługiwany z Nginx, będzie znacznie szybszy w IIS 7 (zakładając, że czas dostępu do bazy danych będzie taki sam w obu przypadkach). Czy to uczciwe założenie?

Edytować:

Napisz od Karla za pomocą Nginx przed IIS7


Zauważ, że serverfault.com już używa Nginx (według Wappalyzer ). : P
WillS

Odpowiedzi:


26

Ta prezentacja może zawierać przegląd wewnętrznych elementów nginx. Główną różnicą jest asynchroniczna obsługa żądań zamiast używania wątków, tak jak robi to Apache. Możesz także zajrzeć do tej dokumentacji .


2
Dobra odpowiedź na temat architektury nginx i problemu C10K. Rozumiem jednak, że pytanie dotyczące PO dotyczy postrzeganej prędkości ładowania strony, która ma niewiele wspólnego z nginx.
Jesper M,

Co tak naprawdę oznacza „asynchroniczny”? Zawsze myślałem, że oznacza to wykonanie osobnego wątku.
Ivan

Średnia asynchroniczna Nginx działa zawsze jako serwer proxy, nawet z Php: Nginx otrzymuje żądanie HTTP, wysyła do serwera php, ALE nie blokuje / nie oczekuje na wysłanie odpowiedzi HTTP. Dlatego widzisz różnicę (prędkość, procesor / pamięć RAM) w witrynie o dużym ruchu. Ale nie ma wzrostu wydajności dla kilku żądań (które dotyczą 95% internetu ....), ale Nginx jest fajny ;-)
Thomas Decaux

21

W jaki sposób strona taka jak rambler dostarcza tak dynamiczną zawartość? ... Czy jest to czysto zdolność Nginx? Gdzie powinienem szukać informacji o takich możliwościach?

Nie ma to nic wspólnego z używanym serwerem WWW - zarówno nginx, IIS, jak i Apache są „wystarczająco szybkie” i generalnie wykonują swoją pracę w ciągu milisekund. nginx jest znacznie szybszy niż Apache, ale oznacza to tylko, że właściciel strony będzie potrzebował mniej serwerów dla części obsługującej strony internetowe - nginx nie przesyła danych szybciej do ciebie.

Mniej istotną częścią jest szybkość po stronie serwera , tj. Czas potrzebny do utworzenia HTML. Ważniejszą częścią jest wydajność „frontendu” , przez którą rozumiem HTML, CSS, JavaScript i obrazy, ich liczbę, rozmiar i prawidłowe dostarczanie (kompresja HTTP, buforowanie).

Oczywiście szybkość po stronie serwera jest nadal ważna, nie twierdzę, że należy ją zignorować lub że nie ma to znaczenia. Ale zazwyczaj jest to najmniejsza część postrzegana jako szybkość użytkownika końcowego - praca na serwerze jest często wykonywana w mniej niż 500 milisekund, ale strona nie jest gotowa przed upływem 3000-5000 milisekund. Większość czasu poświęcana jest na pobieranie zasobów interfejsu użytkownika (CSS, JavaScript, obrazy).

Steve Souders wykonał oryginalną pracę w Yahoo, teraz pracuje w Google. Jego pierwsza książka „Witryny o wysokiej wydajności” jest najlepszym punktem wyjścia do zdobywania wiedzy na temat tworzenia szybkich stron internetowych. Ten sam materiał, który znajduje się w jego książce, można znaleźć w tej rozmowie wideo i tych zasadach projektowania . Uważam jednak, że książka jest szybka do przeczytania i znacznie łatwiejsza do zrozumienia.

Witryny można uruchamiać za pomocą testera WebPageTest.org - daje to dobre wyczucie części frontonu tych witryn i dlaczego są one szybsze lub wolniejsze.

Wierzę, że serverfault.com, jeśli zostanie dostarczony z Nginx, będzie znacznie szybszy w IIS 7 (zakładając, że czas dostępu do bazy danych będzie taki sam w obu przypadkach). Czy to uczciwe założenie?

Nie, to nieporozumienie. :-)


18

Nginx jest częściej wykorzystywany do równoważenia obciążenia innych aplikacji / serwerów i udostępniania treści statycznych niż jako kompletny serwer.

Na przykład możesz napisać aplikację przy użyciu jednego z wielu frameworków Pythona, a nginx może być frontendem dla wielu takich przypadków (być może rozproszonych na kilku komputerach). W tym przypadku serwery nginx służą dwóm celom: bezpośrednio obsługują żądania treści statycznych, takich jak obrazy i arkusze stylów (a ze względu na swoją konstrukcję robi to bardzo szybko) i przekazują dynamiczne żądania do aplikacji, rozkładając obciążenie między wszystkie instancje, o których wie . Jest to bardzo popularna konfiguracja również w społeczności Ruby on Rails.

Istnieją dwa inne możliwe powody, dla których Rambler może pojawiać się szybciej niż lokalna usługa Yahoo. Po pierwsze, lokalny punkt dostępowy Yahoo może po prostu nie mieć wystarczającej ilości zasobów, aby obsłużyć liczbę żądań, które dostaje szybciej, więc może po prostu dodanie większej ilości sprzętu (zakładając, że oprogramowanie skaluje się w ten sposób) przyspieszy (ale przypuszczalnie różnica nie jest warte utrzymania dodatkowego zestawu lub Yahoo by to zrobił). Inną dużą różnicą może być raczej zaplecze niż serwer WWW - te dwie usługi bez wątpienia będą miały bardzo różne układy baz danych, a nawet jeśli nie, prawdopodobnie nie uruchomią dokładnie takiej samej różnorodności zapytań (i ilości Istotny wpływ będzie miał również sprzęt dedykowany do archiektury bazy danych).

Analiza, dlaczego jedna usługa jest szybsza od drugiej (ogólnie lub w określonych okolicznościach) zwykle nie przyniesie jednej prostej odpowiedzi - istnieje wiele sposobów zaprojektowania aplikacji, która ma być skalowana do wielu tysięcy użytkowników, z których każda ma swoją własne korzyści, problemy i kompromisy, a nawet jeśli weźmiesz pod uwagę wszystkie różnice, każda witryna będzie miała inną dynamikę bazową dla użytkowników, a także problemy z siecią pozostające poza kontrolą projektantów.


3

nginx prawdopodobnie, ale bardziej skalowalna architektura z rozsądnym równoważeniem obciążenia przed statycznymi serwerami treści / dynamicznymi generatorami treści. jeśli naprawdę chcesz uzyskać wspaniałe wrażenia dla użytkowników końcowych, prawdopodobnie powinieneś przenieść zawartość bliżej „gałek ocznych” - użyj CDN.

jeśli jesteś zainteresowany tematem - sprawdź to i tamto i ... no cóż - google; -]


2

Najlepsze strony używają akceleratorów aplikacji, takich jak ZXTM Zeusa - mogą buforować dynamiczne odpowiedzi w wielu przypadkach, co oczywiście jest wielką zaletą.



0

Mam problem z szybszym zauważeniem błędu serwera (SO może mieć problemy z ładowaniem z powodu ruchu?), Ponieważ jest to natychmiastowe ładowanie strony tutaj w UE na mojej trasie. Jest o wiele szybszy i bardziej responsywny niż większość lokalnych serwisów informacyjnych i tak dalej.

Większość oczywistych problemów związanych z czasem ładowania i opóźnieniami pochodzi od serwera i końcowego użytkownika imo, a nie rzeczywistej wydajności serwera (chyba że ktoś źle dobrał lub zaprojektował coś złego). Różne strony mogą być kierowane na różne sposoby i istnieje duża możliwość, że lokalna witryna dla mnie ma większe opóźnienia niż coś na całej planecie - wszystko zależy od tak wielu zmiennych, że nie można powiedzieć, że można ją rozwiązać tylko przez usługę uaktualnij / zmień, chyba że wiesz, że właśnie tam problemem dla określonego zastosowania (r) jest ...

Oczywiście buforowanie różnego rodzaju na serwerze robi dużą różnicę, ale o ile wiem, wszystkie te strony już to robią.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.