Jak pokazują badania Netcraft z marca br., Nginx systematycznie atakuje drugą pozycję niezagrożonego do tej pory Microsoft IIS (Internet Information Services). Miesięczny przyrost instalacji serwera open source to około 0,25%, przy spadku IIS o blisko 0,58%. Oznacza to, że przejęcie drugiej pozycji przez Nginx może nastąpić w ciągu kilku miesięcy.

Gdy weźmiemy pod uwagę tylko aktywne serwisy, czyli takie, które mają unikalną zawartość i nie są generowane z szablonów (templates), to rosyjski serwer już wyprzedził IIS w proporcjach: 12,18 do 12,14. Jeszcze bardziej imponująco rysuje się obraz popularności Nginxa wśród 1000 najbardziej obciążonych serwisów internetowych. Około 25% z nich korzysta właśnie z tego serwera, i są wśród nich, tacy giganci jak: Facebook, Zappos, Groupon, Hulu, Dropbox oraz WordPress.

Zobacz również:

• Wielka inwestycja Atmana w przetwarzanie danych
• AI ma duży apetyt na prąd. Google znalazł na to sposób
• OpenAI rozważa stworzenie własnych układów scalonych AI

Główne zalety tego rozwiązania to wydajność i niskie obciążenie zasobów, które czynią z niego idealne rozwiązanie wszędzie tam, gdzie mamy do czynienia z dużym ruchem, oraz gdy nie dysponujemy zbyt wydajnym serwerem. Dynamika adaptacji serwera Nginx znacznie wzrosła po przekształceniu projektu rosyjskich programistów (Igor Sysojew i Andriej Aleksiejew) w firmę i pozyskaniu finansowania w wysokości 3 mln dolarów w lipcu ub.r.

Duża wydajność, ale nie zawsze

Nginx (skrót od Enigne-X) zaprojektowano z myślą o serwisach z bardzo intensywnym ruchem, dochodzącym nawet do 10 tys. jednoczesnych połączeń na serwer. Jedno połączenie wykonywane poprzez Apache może zaalokować nawet kilkanaście czy kilkadziesiąt megabajtów. Nginx - jak przekonują jego twórcy i pokazują wyniki testów - zadowala się kilkudziesięcioma kilobajtami.

Serwer Nginx osiąga najwyższą wydajność serwując zawartość statyczną. Natomiast, gdy część dynamiczna serwisu jest oparta na języku skryptowym PHP, może okazać się, że nie jest to najlepsze rozwiązanie i wybór Apache będzie w pewnych, szczególnych przypadkach korzystniejszy. Dzieje się tak dlatego, że Nginx nie dysponuje specjalnym modułem do obsługi PHP i konieczne jest uruchomienie dodatkowego serwera do obsługi tego języka, np. PHP-FPM. Wtedy Nginx konfiguruje się w taki sposób, żeby obsługa skryptów była przekazywana poprzez PHP-FPM. Powoduje to opóźnienia i konieczność uruchomienia dodatkowego procesu, co wiąże się z wydłużeniem czasu operacji i zapotrzebowaniem na procesor i pamięć. W przypadku Apache wyposażonego w moduł mod_php - takiego problemu nie ma. Należy pamiętać, że każdy wątek Apache z mod_php niezależnie, czy serwowana jest zawartość statyczna czy dynamiczna, jest obciążony inicjalizacją interpretera PHP.