htmlNGINX vs. Apache: Jak wybrać najlepszy serwer WWW

Wyobraź sobie to: szukasz nowych butów sportowych, znajdujesz dobrą ofertę i decydujesz się to sprawdzić na stronie internetowej.

Czekasz 10 sekund… 20 sekund… i strona wciąż się nie ładuje. Masz dość czekania, więc przechodzisz na inną stronę. Oto co prawdopodobnie się stało: strona z butami sportowymi prawdopodobnie poświęciła dużo czasu i pieniędzy na efektowne zdjęcia i eleganckie projekty, ale to wszystko na nic, jeśli ładowanie trwa wieczność.

Internet jest pełen wolnych stron internetowych.

Średnia strona docelowa na urządzenia mobilne ładuje się w 22 sekundy, a to jest fatalne dla biznesu.

Badanie przeprowadzone przez Portent wykazało, że strona, która ładuje się w mniej niż sekundę, ma trzykrotnie wyższą stopę konwersji niż strona, która ładuje się pięć sekund.

A teraz, co to ma wspólnego z naszym porównaniem NGINX vs. Apache?

Głównym czynnikiem wpływającym na szybkość strony jest Twój serwer internetowy — oprogramowanie, które dostarcza Twoje strony do odwiedzających.

Apache i NGINX to dwa z najbardziej znanych serwerów internetowych.

Według danych z lipca 2024 roku, w3techs donosi, że NGINX zasila ponad 34% stron internetowych, podczas gdy Apache obsługuje 29,4%.

Czy to czyni NGINX niekwestionowanym zwycięzcą? Jeszcze nie.

Oba serwery internetowe działają różnie w zależności od przypadków użycia. W tym przewodniku przyjrzymy się różnicom między Apache a NGINX i wyjaśnimy, na co zwrócić uwagę przy wyborze serwera.

Zacznijmy.

Czym są serwery internetowe?

Serwery internetowe to aplikacje programowe, które działają na fizycznym serwerze i obsługują przychodzące żądania użytkowników.

Kiedy wpisujesz URL takie jak „google.com”, Twoja przeglądarka wysyła żądanie do serwera internetowego, który przechowuje pliki wymagane do działania strony internetowej.

Serwer następnie odsyła odpowiednią treść, czy to HTML, CSS, JavaScript, obrazy lub inny typ.

Serwery internetowe obsługują wiele ważnych zadań w tle:

• Zarządzanie połączeniami i żądaniami HTTP
• Kierowanie żądań do odpowiedniej aplikacji backend, jeśli jest to potrzebne (jak PHP, Python, lub Ruby on Rails)
• Odczytywanie i zapisywanie plików z dysku w celu obsługi statycznych zasobów
• Wprowadzenie polityk bezpieczeństwa
• Kompresowanie zawartości w celu przyspieszenia transmisji
• Rejestrowanie żądań w celu analizy

Teraz, gdy omówiliśmy, jak działają serwery internetowe, zobaczmy, jak NGINX i Apache podchodzą do tych zadań.

Co to jest Apache?

Serwer HTTP Apache, potocznie nazywany Apache, to popularne oprogramowanie serwera internetowego typu open-source stworzone przez Roberta McCoola i wydane w 1995 roku. Bazuje na serwerze NCSA HTTPd.

Fundacja Apache Software, organizacja non-profit wspierająca projekty oprogramowania open-source, opracowała i nadal utrzymuje je.

Przez wiele lat, Apache był najczęściej używanym serwerem internetowym na świecie, napędzając wiele stron internetowych. W rzeczywistości, odegrał znaczącą rolę w rozwoju Światowej Sieci Web w jej początkowych dniach.

Niektóre z kluczowych funkcji i korzyści Apache to:

• Modularna architektura: Jej funkcjonalność może być rozszerzana za pomocą modułów dla różnych funkcji i języków.
• Działa na różnych systemach operacyjnych: Apache jest zbudowany jako wieloplatformowy, aby hostować Twój serwer internetowy na dowolnym systemie operacyjnym, w tym Linux, Windows i macOS.
• Bogata dokumentacja i duża społeczność: Pomaga użytkownikom i programistom rozwiązywać problemy oraz rozwijać lepsze rozwiązania podczas współpracy.
• Elastyczna konfiguracja: Pliki .htaccess mogą ułatwić użytkownikom dokonywanie zmian konfiguracyjnych specyficznych dla katalogów.
• Funkcje bezpieczeństwa: Apache posiada dość dobre zabezpieczenia dzięki swojej otwartej naturze i regularnym aktualizacjom naprawiającym luki i błędy.

Mimo to, Apache ma kilka ograniczeń:

• Wyższe zużycie pamięci: Używa więcej pamięci niż NGINX, szczególnie przy obsłudze wielu równoczesnych połączeń.
• Wolniejszy przy dużym obciążeniu: Może być wolniejszy od NGINX przy obsłudze plików statycznych, zwłaszcza przy dużym obciążeniu.
• Trudniejszy dla programistów do rozwijania i utrzymania: Na przestrzeni lat rosnąca złożoność bazy kodu uczyniła go trudniejszym do budowania i utrzymania.

Czym jest NGINX?

NGINX (wymawiane „Engine X”) to darmowe, otwartoźródłowe oprogramowanie serwera internetowego o wysokiej wydajności, które zostało po raz pierwszy wydane w 2004 roku. Zostało stworzone przez Igora Sysoeva, rosyjskiego inżyniera oprogramowania, aby rozwiązać problem obsługi wielu użytkowników odwiedzających stronę internetową jednocześnie, co stanowiło wyzwanie dla innych serwerów internetowych, takich jak Apache.

Praca Sysoeva nad NGINX rozpoczęła się w 2002 roku. Jego celem było rozwiązanie “problemu C10k” — obsługi 10 000 równoczesnych połączeń.

Jego wizja to szybki, stabilny i skalowalny serwer. To skupienie na wydajności sprawia, że NGINX jest wyjątkowo dobry w obsługiwaniu statycznych treści, takich jak strony HTML, obrazy i pliki CSS.

Poza swoją prędkością, NGINX wyróżnia się jako odwrotny serwer proxy. Odbiera żądania użytkowników i inteligentnie kieruje je do innych serwerów, takich jak Apache czy aplikacje internetowe, optymalizując wykorzystanie zasobów.

Niektóre z głównych zalet NGINX to:

• Obsługa równoczesna: NGINX obsługuje wielu użytkowników jednocześnie bez wymagania nadmiernego wykorzystania pamięci lub mocy CPU.
• Łatwy w konfiguracji i instalacji: NGINX posiada prosty i intuicyjny format pliku konfiguracyjnego, który pomaga użytkownikom łatwo konfigurować serwer sieciowy zgodnie z ich przypadkiem użycia.
• Różnorodne funkcje poprawiające wydajność: NGINX posiada wiele wbudowanych funkcji do balansowania obciążenia, Pamięć podręczna i zabezpieczania stron internetowych za pomocą szyfrowania SSL/TLS.
• Obsługuje IMAP i POP3: NGINX funkcjonuje również jako serwer proxy pocztowy, obsługujący protokoły takie jak IMAP i POP3.

Jednakże, istnieje kilka wad związanych z używaniem NGINX:

• Domyślne ustawienia nie są optymalne: Domyślne algorytmy równoważenia obciążenia mogą nie zawsze działać optymalnie w każdej sytuacji.
• Brak wbudowanych kompilatorów języków: Nie obsługuje natywnie tworzenia dynamicznych stron internetowych przy użyciu języków serwerowych takich jak PHP czy Python. Mimo to, można obejść to za pomocą rozszerzenia stron trzecich.

Apache vs. NGINX: Jakie są różnice?

Apache kiedyś był najlepszym wyborem jako serwer sieciowy. Jednak NGINX szybko przejął udział w rynku i obecnie jest popularny wśród wielu stron o dużym ruchu.

Jeśli planujesz pracować z dedicated hosting, wybór odpowiedniego serwera internetowego jest ważną decyzją.

Więc co je różni?

Przyjrzyjmy się temu bliżej.

Szczegóły	Serwer HTTP Apache	NGINX
Założony	1995	2004
Warunki licencyjne	Licencja Apache 2.0	Licencja BSD w dwóch klauzulach
Kompatybilność z systemami operacyjnymi	Windows, Linux, macOS, systemy oparte na Unix	Windows, Linux, macOS, systemy oparte na Unix
Wsparcie dla protokołu WebSocket	Tak	Tak (wprowadzone w wersji 1.3.13)
Wsparcie dla proxy odwrotnego	Tak	Tak
Konfiguracja hosta wirtualnego	Wspierane	Wspierane
Pamięć podręczna	Dostępna poprzez moduły	Wbudowana w rdzeń
Zużycie zasobów (pamięć)	Wysokie	Niskie
Format konfiguracji i instalacji	Oparty na tekście	Opisany na tekście (prostsza składnia)
Funkcje bezpieczeństwa	Wsparcie mod_security zapewnia elastyczną konfigurację reguł i kontrolę dostępu	Zaawansowane filtrowanie, limitowanie szybkości, wbudowane wsparcie dla łagodzenia DDoS oraz wydajność SSL/TLS
Zaszyfrowana komunikacja (SSL/TLS)	Wspierane	Wspierane
Obsługa równoczesnych połączeń	Dobra	Bardzo wydajna
Wydajność skalowania	Dobra	Znakomita
Funkcjonalność dystrybucji obciążenia	Osiągalna za pomocą modułów	Cecha wbudowana
Ogólna wydajność i szybkość	Zadowalająca	Dwa razy szybsza niż Apache

Architektura i współbieżność

Jedną z najważniejszych różnic między NGINX a Apache jest sposób, w jaki obsługują przychodzące żądania w tle.

To ma znaczący wpływ na ich wydajność i efektywność zasobów.

Architektura Procesowa Apache

Apache stosuje model oparty na procesach, tworząc nowy wątek lub proces dla każdego przychodzącego żądania.

Te procesy lub wątki są zarządzane przez moduły wieloprocesowe (MPMs):

• Prefork MPM: Oryginalny model Apache. Każdy proces ma jeden wątek i obsługuje jedno połączenie na raz. Jest proste, ale może być intensywne pod względem pamięci.
• Worker MPM: Używa wielu wątków na proces, każdy obsługujący pojedyncze połączenie. Jest lepsze niż prefork pod względem pamięci, ale intensywny ruch i zasobożądne żądania mogą nadal powodować przeciążenie procesora, prowadząc do problemów z wydajnością.
• Event MPM: Podobne do worker MPM, ale zoptymalizowane pod kątem połączeń utrzymywanych (urządzenia, które nie mogą być odłączone od serwera). Jednakże, nadal nie jest w pełni asynchroniczne.

To są wszystkie dobre moduły, ale mają jedną poważną wadę: Apache musi tworzyć nowe procesy lub wątki dla każdego przychodzącego połączenia i niszczyć je po zakończeniu. Stara się zarządzać tym przez wcześniejsze utworzenie kilku bezczynnych procesów.

Jednakże, jeżeli kilka osób chce jednocześnie połączyć się ze stroną, Apache może przekroczyć istniejący pulę, a wtedy musi szybko utworzyć więcej procesów. To zajmuje czas i zużywa pamięć.

Ten model działa doskonale dla stron o niskim do średnim ruchu. Mimo to, Apache może zacząć obciążać strony z wieloma równoczesnymi połączeniami.

Wszystkie te oddzielne procesy nie są zbyt wydajne. Nawet przy użyciu event MPM, Apache nie jest w stanie całkowicie wydostać się z modelu jednego wątku na połączenie.

Architektura zdarzeniowa NGINX

NGINX podejmuje bardzo różne podejście. Zamiast oddzielnych procesów lub wątków dla każdego połączenia, NGINX wykorzystuje asynchroniczną, sterowaną zdarzeniami architekturę.

Oto jak to działa: 

• NGINX ma główny proces (zazwyczaj jeden na rdzeń procesora), który zarządza kilkoma procesami pracowniczymi. Każdy pracownik może obsłużyć tysiące jednoczesnych połączeń. Nie ma potrzeby, aby pracownicy tworzyli nowe wątki czy przekierowywali każde zapytanie do dedykowanego procesu.
• Zamiast tego, pracownicy mają pętlę zdarzeń, gdzie efektywnie obserwują nowe zdarzenia na istniejących połączeniach przy użyciu mechanizmów systemu operacyjnego, takich jak kqueue czy epoll. Pozwala im to żonglować wieloma połączeniami w ramach jednego wątku. Gdy zdarzy się coś, jak nowe zapytanie czy odpowiedź serwera backendowego, NGINX szybko przekierowuje to do wolnego slotu w pracowniku.
• Jest to o wiele bardziej efektywne niż model Apache. NGINX może obsłużyć ogromną liczbę zapytań przy niewielkim zużyciu pamięci. Skaluje się niezwykle dobrze, co jest powodem, dla którego jest używany na wielu najbardziej ruchliwych stronach w internecie.

Wadą jest to, że NGINX nie może osadzać interpreterów kodu tak jak Apache.

Więc, gdy chcesz uruchomić kod PHP lub Python, NGINX przekazuje żądania do oddzielnego menedżera procesów FastCGI, takiego jak php-fpm. Ten proces uruchamia kod i tłumaczy go na coś, co przeglądarka użytkownika może zrozumieć.

Z drugiej strony, Apache może uruchamiać języki takie jak PHP, Perl i Python w ramach swoich procesów.

Skoro NGINX nie może, plik config może stać się nieco bardziej złożony.

Korzyści z wydajności zwykle przewyższają trudy.

Wydajność

NGINX jest znany z wysokiej wydajności przy obsłudze statycznych plików takich jak strony HTML, obrazy, CSS oraz JavaScript.

Architektura sterowana zdarzeniami pomaga, ale NGINX ma również inne sztuczki.

Po pierwsze, w przeciwieństwie do Apache, NGINX nie musi przechodzić przez pamięć podręczną i uderzać w dysk za każdym razem, gdy jest żądanie. Może serwować pliki bezpośrednio z dysku. Ponadto, NGINX eliminuje nadmiarowe obciążenie związane ze sprawdzaniem uprawnień i blokowaniem plików.

Apache ma te problemy, ponieważ każde żądanie to proces, i jeśli jeden proces coś modyfikuje, to inny proces nie może jednocześnie korzystać z tego samego pliku.

Podczas gdy mniejsze strony internetowe nie zauważą tego wąskiego gardła ze względu na szybkość przetwarzania w tle, duże strony z kilkoma tysiącami żądań na sekundę zaczną doświadczać spowolnienia, które wpływa na doświadczenia użytkownika.

NGINX posiada również wbudowaną pamięć podręczną plików. Przy pierwszym żądaniu pliku, NGINX odczytuje go z dysku i umieszcza w swojej pamięci podręcznej. Kolejne żądania tego pliku mogą być obsługiwane błyskawicznie prosto z pamięci, bez konieczności sięgania do dysku. Automatycznie unieważnia też dane w pamięci podręcznej, jeśli plik na dysku ulegnie zmianie.

Te optymalizacje sumują się. W testach porównawczych, NGINX może często obsługiwać statyczne pliki około trzy razy szybciej niż Apache, szczególnie gdy liczba równoczesnych żądań wzrasta.

Dodatkowo: to może również pomóc poprawić Twoje podstawowe wskaźniki witryny, dając Ci nieco przewagi na Google.

Apache również nie jest wolny. Musisz poświęcić czas na jego odpowiednią konfigurację, aby działał właściwie. Jest również zdolny do bardzo szybkiego serwowania plików statycznych.

Ale NGINX to najlepsze rozwiązanie, jeśli chcesz mieć wydajny serwer internetowy od razu po wyjęciu z pudełka.

Konfiguracja i Składnia

NGINX i Apache mają różne filozofie konfiguracji.

Apache jest znany ze swoich rozległych opcji konfiguracji. Oprócz pliku apache2.conf, musisz dodać swoje reguły i konfiguracje do pliku .htaccess .

Pliki konfiguracyjne używają składni podobnej do XML i oferują niesamowitą elastyczność. Apache posiada obszerną listę dyrektyw, które można wykorzystać do dostosowania każdego aspektu zachowania serwera.

Możesz ustawić opcje konfiguracji globalnie lub zastąpić je dla konkretnych katalogów lub hostów wirtualnych.

Prawdziwa moc Apache pochodzi z jego rozległego ekosystemu modułów. Ogromna gama oficjalnych i stron trzecich modułów Apache pozwala na wszystko, od przepisywania adresów URL po filtrowanie bezpieczeństwa i zaawansowaną pamięć podręczną. Aby użyć modułu, musisz go załadować w swojej konfiguracji Apache.

Drugą stroną medalu jest to, że konfiguracja Apache może szybko stać się skomplikowana, szczególnie dla zaawansowanych ustawień. Dyrektywy mogą wzajemnie się nadpisywać w skomplikowanych łańcuchach dziedziczenia. Opcje konfiguracji często są rozdzielone na wiele plików w różnych podkatalogach głównego folderu config. To jest super elastyczne, ale wymaga czasu, aby to opanować.

Konfiguracja NGINX, z drugiej strony, dąży do prostoty i czytelności. Nie ma tutaj pliku .htaccess. Po prostu konfigurujesz strony w swoim pliku NGINX.conf wraz z folderem sites-enabled, i wszystko jest gotowe.

Składnia zapożycza stylizację z popularnych języków programowania. Nadal jest potężna, ale nie tak rozbudowana jak Apache.

Zamiast modułów, NGINX posiada mniejszy zestaw podstawowych dyrektyw i funkcji, które są wbudowane. Wszystkie opcje dla danej funkcji zazwyczaj znajdują się razem w jednym bloku (zamknięte w nawiasach klamrowych { }).

Niektóre zaawansowane funkcje, takie jak równoważenie obciążenia i pamięć podręczna, są konfigurowane w głównym NGINX.conf, a nie w oddzielnych plikach bocznych.

Rezultatem jest to, że pliki konfiguracyjne NGINX są zwykle bardziej zwięzłe i łatwiejsze do czytania oraz konfiguracji niż obszerne pliki Apache, ale nadal można z nimi wiele zrobić.

Bezpieczeństwo

NGINX i Apache to projekty typu open-source z dużymi, aktywnymi społecznościami programistów nieustannie pracujących nad identyfikacją i łataniem luk. Oba otrzymują regularne aktualizacje bezpieczeństwa i mają dobre wyniki w szybkim rozwiązywaniu problemów.

Mimo to, istnieją pewne różnice w podejściu do bezpieczeństwa.

Oto kilka kluczowych punktów do rozważenia:

• Modularność: Modularna architektura Apache oznacza, że możesz włączyć tylko te funkcje, które używasz, minimalizując powierzchnię ataku. W przypadku NGINX wiele standardowych funkcji jest wbudowanych bezpośrednio w rdzeń, co niektórzy mogą uznać za mniej elastyczne z punktu widzenia bezpieczeństwa.
• Filtrowanie żądań: NGINX posiada potężny wbudowany silnik filtrowania żądań, który może pomóc blokować powszechne ataki internetowe takie jak iniekcja SQL i skrypty międzywitrynowe (XSS). Apache posiada podobne możliwości dzięki modułom takim jak mod_security.
• Konfiguracja SSL/TLS: Obie serwery obsługują SSL/TLS dla szyfrowanych połączeń, ale mówi się, że NGINX jest łatwiejszy w konfiguracji. Posiada bardziej przejrzystą dokumentację i bezpieczniejsze domyślne ustawienia.
• Izolacja procesów: Użycie przez NGINX jednego procesu głównego z wieloma procesami pracującymi może pomóc izolować problematyczne obszary. Prefork oraz worker MPM w Apache mogą zapewnić podobną izolację na poziomie procesów, ale kosztem większego zużycia zasobów.
• Łagodzenie ataków DDoS: Architektura sterowana zdarzeniami i efektywne zarządzanie jednoczesnymi połączeniami sprawiają, że NGINX jest popularnym wyborem do łagodzenia ataków DDoS od małych do średnich rozmiarów. Kilka dodatkowych modułów i strojenie mogą również uczynić Apache odpornym na ataki DDoS.

Dynamiczna zawartość, moduły i ekosystem

Apache od dawna jest wyborem dla serwowania dynamicznej treści, ponieważ łatwo integruje języki serwerowe. Dzięki MPM-om prefork i worker, możesz kompilować wsparcie dla języków takich jak PHP, Python i Perl bezpośrednio w pliku binarnym Apache.

Apache następnie uruchomi interpreter w każdym ze swoich procesów pracowniczych. To jest proste i przyjemne — Apache może przekazywać żądania dotyczące plików .php do wbudowanego interpretera PHP i otrzymywać z powrotem przetworzone dane wyjściowe.

NGINX nie posiada wbudowanego wsparcia dla języków serwerowych. Potrzebujesz oddzielnej usługi takiej jak php-fpm, która uruchamia interpreter języka, aby uruchomić PHP, Python, lub Ruby on Rails z NGINX. NGINX odbiera żądania i przekazuje je do backendu, który przetwarza kod i zwraca odpowiedź.

Wymaga to trochę więcej pracy przy konfiguracji niż podejście wszystko w jednym Apache. Z drugiej strony, pasuje to do filozofii NGINX-a polegającej na robieniu jednej rzeczy (obsłudze żądań) — i robieniu tego dobrze.

Jeśli chodzi o inne funkcje, NGINX jest wyposażony w solidne podstawowe funkcje, takie jak równoważenie obciążenia, proxy, pamięć podręczna, limitowanie szybkości, kompresja i zakończenie SSL. Jednak nie dorównuje niesamowitej różnorodności ekosystemu modułów Apache. W Apache masz moduły do schematów uwierzytelniania, filtrowania treści, wbudowanych języków skryptowych i nie tylko.

Nie każdy z tych elementów jest unikalny. NGINX może wykonywać wiele tych samych zadań, tylko na różne sposoby. Jednakże, biblioteka modułów Apache jest dość obszerna.

Jeśli potrzebujesz jakiejś super-szczegółowej funkcjonalności, Apache może mieć tutaj przewagę.

Mimo to, zestaw funkcji NGINX jest solidny pod kątem większości typowych potrzeb serwowania stron internetowych.

Rzeczywiste zastosowanie, wydajność i społeczność

Popularność NGINX wzrosła w ciągu ostatniej dekady.

Od 2022 roku napędza ponad 34% wszystkich stron na świecie, w porównaniu do około 29% w przypadku Apache.

Jedna rzecz, którą powinieneś mieć na uwadze: nie zauważysz różnicy między tymi serwerami internetowymi, chyba że masz dużą stronę lub naprawdę mały serwer.

Załóżmy, że podoba ci się szeroka konfiguracja Apache i zintegrowane podejście do dynamicznej zawartości. Dokumenty Apache są jednymi z najlepszych, a społeczność jest ogromna, jeśli kiedykolwiek będziesz potrzebować pomocy.

NGINX może być lepszym wyborem, jeśli dążysz do maksymalnej współbieżności lub budujesz ogromną stronę. Jego architektura jest nieco bardziej przyszłościowa i stworzona do skalowania. Społeczność NGINX również szybko się rozwija. Dokumentacja jest również solidna; można znaleźć mnóstwo poradników i wsparcia.

Apache vs. NGINX: Który jest odpowiedni dla Ciebie?

Nie ma jednej odpowiedzi na debatę NGINX vs. Apache. Niemniej jednak, oto kilka ogólnych zasad, które mogą pomóc Ci podjąć decyzję.

NGINX jest lepszy, gdy:

• Masz stronę o bardzo wysokim ruchu.
• Musisz szybko udostępniać mnóstwo statycznych zasobów.
• Budujesz architekturę mikrousług.
• Preferujesz bardziej uproszczony styl konfiguracji.
• Używasz kontenerów lub hostingu chmurowego, gdzie każdy gram pamięci ma znaczenie.

Apache jest lepszy, jeśli:

• Potrzebujesz głębokiej kompatybilności z funkcjami tylko dla Apache, takimi jak .htaccess.
• Chcesz moduły do bardzo specyficznych funkcjonalności.
• Potrzebujesz uruchomić starsze aplikacje internetowe stworzone dla Apache i mod_php.
• Po prostu lubisz system konfiguracji Apache.
• Twój serwer jest głównie maszyną deweloperską, a wydajność jest mniej krytyczna.

Nie ma reguły, która mówi, że musisz wybrać tylko jedną opcję.

Uruchamianie NGINX przed Apache jako reverse proxy jest bardzo powszechne. Pozwala to na połączenie niezrównanej obsługi plików statycznych i równoczesnego przetwarzania przez NGINX z bogatym wsparciem dla dynamicznych języków przez Apache na backendzie — najlepsze z obu światów.

Podsumowanie

Apache i NGINX są świetne, więc wybór jednego z nich zależy głównie od tego, co najlepiej odpowiada Twoim potrzebom.

Pamiętaj, że nawet najmocniejszy serwer to tylko jedno z kół zębatych w maszynie. Więc, jeśli strona działa powoli, oprogramowanie lub sprzęt serwera niekoniecznie powinny być pierwszą rzeczą do optymalizacji.

Mądrzejsze korzystanie z pamięci podręcznej, strojenie bazy danych, optymalizacja kodu oraz solidne podstawy sprzętowe mogą wszystkie przyspieszyć pracę Twojego stosu więcej niż spędzanie godzin na zabawie z NGINX lub Apache.

Jeśli potrzebujesz serwera do eksperymentów, wypróbuj zarządzany VPS DreamHost. Posiadając VPS, możesz wybrać, jakie oprogramowanie zainstalować, jak serwer powinien reagować na żądania i więcej. Ponadto, dzięki elastyczności VPS, możesz hostować wiele stron internetowych na jednym serwerze i odpowiednio dzielić między nimi zasoby.

Dodatkowo, wszystkie plany DreamPress teraz zawierają NGINX.

Jedynym sposobem na znalezienie idealnej konfiguracji jest eksperymentowanie. Uruchom VPS, zainstaluj NGINX i Apache, i sprawdź, które z nich najlepiej działa dla Ciebie!