Lakier -> Nginx -> Apache dobry pomysł?

10

Myślę o architekturze nowego serwera WWW. Czy posiadanie Varnish jako pamięci podręcznej przed Nginx jako odwrotnego serwera proxy i podawanie plików statycznych przed apache do wszystkich ciężkich operacji podnoszenia byłoby dobrym pomysłem?

Zamierzam uruchamiać aplikacje php i ruby ​​na szynach.

Czy będzie za dużo narzutów, przesyłając żądania php do apache przez dwa inne procesy?

Wielkie dzięki!

apache-2.2 nginx architecture varnish Zoran Zaric
źródło

Odpowiedzi:

8

Tak, to jest ważne. Moim osobistym podejściem byłoby użycie Varnish z przodu i użycie VCL do podzielenia ruchu pomiędzy statycznymi żądaniami NGINX a ciężkim podnoszeniem (czy to będzie Apache, czy Pasażer, czy ... to nie ma znaczenia). Jest to szczególnie prawdziwe, jeśli znajduje się na tej samej maszynie, ponieważ nie potrzebujesz dodatkowego obciążenia. To niekoniecznie nic ci kupuje.

McJeff
źródło
tak, to całkiem niezły pomysł, ponieważ lakier powinien być na to dość szybki
Zoran Zaric
6

Lakier nie obsługuje (jeszcze) kompresji gzip, więc może być pomysł zamiany go z nginx z przodu, aby skompresować to, co lakier wysyła. Ponieważ lakier i nginx nie walczą o te same zasoby (nginx używa procesora do kompresji gzip, a lakier używa pamięci), powinny działać płynnie na tym samym komputerze.

Lakier obsługuje teraz kompresję gzip , więc jeśli nie potrzebujesz zakończenia SSL (jak sugerowano w komentarzach), sugerowałbym skontaktowanie lakieru bezpośrednio z Internetem.

Dla http:

(internet) -> (lakier, gzip, buforowanie, esi) -> (aplikacja)

Dla https:

(internet) -> (nginx, ssl) -> (lakier, gzip, buforowanie, esi) -> (aplikacja)

Jeśli chcesz tam również apache (dla wszechobecnej obsługi mod_foobar), umieściłbym go między lakierem a aplikacją

Aktualizacja: Zaktualizowano w celu uwzględnienia obsługi gzip w lakierze 3.0. Dodano ssl / esi zgodnie z sugestiami w komentarzach

mogsie
źródło
Jeśli cokolwiek obsługuje zawartość do lakierowania, koduje ją w gzipie, wtedy lakier przekaże ją do gzipa bez narzekań: varnish-cache.org/wiki/FAQ/Compression Jedyne, czego nie robi lakier, to pobranie zawartości nieskompresowanej z niebuforowanego aplikacji i zarezerwować ją skompresowaną. Czy to również twoje zrozumienie?
ewalk
Jedynym razem, gdy uruchamiasz nginx przed lakierem, jest użycie ESI. Ponieważ nie można wykonać montażu ESI ze skompresowanych stron, a Lakier nie skompresuje złożonej strony, Nginx jest umieszczony przed Lakierem, aby zapewnić tę kompresję. Jeśli pochodzenie obsługuje skompresowaną treść, Varnish przekaże te dane do klienta w skompresowanej formie.
user6738237482
Tak, ESI jest jednym z powodów, dla których zaleciłbym tę konfigurację, ale myślę, że jeśli twój backend kompresuje się i nie używasz ESI, możesz zrezygnować z nginx, ponieważ uważam, że lakier może poradzić sobie z dużym ruchem bez łamanie potu.
mogsie
@ user6738237482, nginx obsługuje zakończenie SSL, Varnish nie. W rzeczywistości bycie przed czymś takim jak lakier lub Apache jest dokładnie tym, dla czego nginx został pierwotnie zaprojektowany, jako szybki, lekki serwer proxy.
rmalayter
4

Wysokość kosztów ogólnych nie powinna być znacząca. Zakładam, że po części chcesz, aby te dwie warstwy były skalowalne; w takim przypadku najprawdopodobniej zobaczysz, w odniesieniu do apache, że lakier i nginx nie pracują bardzo ciężko.

Jeśli wszystkie trzy warstwy na jednym komputerze, zanim osiągniesz pojemność samego serwera, powinno to mieć mniejszy wpływ na wydajność.

Alternatywnie, dlaczego nie lakierować + nginx z pasażerem? Korzystałem z tej konfiguracji w przeszłości i nginx korzystający z pasażera jest stosunkowo lekki i działał całkiem dobrze. Może warto pomyśleć o tym, jeśli nie jesteś żonaty z apache'em prowadzącym swój stos szyn.

Tony
źródło
tak, mogę przejść z Apache na Nginx dla Railsów, ale umożliwienie klientom korzystania z plików .htaccess jest + dla apache, przynajmniej dla PHP.
Zoran Zaric
2

Jestem administratorem sys dla początkowej platformy e-commerce. Używamy lakieru + nginx przed naszym stosem PHP / Apache i zadziałało to cuda.

Mamy aplikację o wysokim zużyciu pamięci, a aplikacja zużywała około 15-20 gigabajtów pamięci RAM na węzeł sieciowy, a po umieszczeniu lakieru z przodu jest teraz około 8 gramów pamięci RAM na węzeł. Nigdy się nie wzbogacili.

Więc bardzo go polecam.

Mikrofon
źródło
3
Wiesz, że lakier nie mówi ssl, prawda?
Mike
1

Używam Drupala z modułem boost na serwerze Apache + PHP + MySQL, ale przed nimi używam Nginx z włączoną funkcją gzip-static i używam wyników boost do obsługi użytkowników.

A na dodatek używam lakieru, wszystkie na tym samym komputerze, mam dobre wyniki.

Używam również Nginx do poprawiania nagłówków, których Drupal nie radzi sobie dobrze w buforowaniu.

Go2linux
źródło
0

To nie jest dobry pomysł, chyba że potrzebujesz czegoś takiego jak ESI. Nginx ma własny system buforowania, który działa lepiej .

VBart
źródło
Wiem, że to stara odpowiedź, ale niestety ten link nie jest już dostępny, więc nie mogę zweryfikować Twojego roszczenia. Z mojego doświadczenia wynika, że ​​Lakier jest trudny do pokonania pod względem szybkości i elastyczności jako odwrotny proxy.
Martijn Heemels,
@MartijnHeemels web.archive.org/web/20130501222206/http: //todsul.com/ ... i jest jeszcze jeden punkt odniesienia: nbonvin.wordpress.com/2011/03/24/...
VBart
-1

Apache może być użyty do zakończenia SSL (odszyfrowania), sprawdź http://noosfero.org/Development/Varnish#SSL

brauliobo
źródło
1
Unikaj publikowania linków jako odpowiedzi, ponieważ Twoja odpowiedź prawdopodobnie straci wszelkie znaczenie, gdy będzie miała na nią wpływ linkrot . Proszę rozważyć edycję swojej odpowiedzi i dołączenie odpowiednich części z linku podanego w odpowiedzi. Jak najbardziej należy pozostawić link jako odniesienie.
Bryan