NGINX + Apache-Kombi = Epic Win

[Lolllipop]

Damit würden die Seiten noch wesentlich schneller ausgeliefert werden ;)
Ich benutze zwar NGINX pur, weil ich mittlerweile Apache hasse wie die Pest, aber die Kombination beider ist auch nicht schlecht.

Kleiner Vergleich von meinem Server (ja, mit passender Konfiguration, ich bin weiss Gott kein Loonix-Noob):
--Apache--
Durchschnittliche Requests pro Sekunde: 357,7
Durschnittliche Requestdauer: 52ms

--NGINX--
Durchschnittliche Requests pro Sekunde: 12.416,3
Durschnittliche Requestdauer: <1ms

Der Apache-Benchmark lief auf eine statische HTML-Datei, welche 1KB groß war.
PHP-Geschwindigkeit (FastCGI bei NGINX, Modul bei Apache), ist über FastCGI (<0,5%) nur leicht schneller, von daher zählt das also nicht.

[Lala Satalin Deviluke]

NGINX? Das kenn ich, aber nur von Fehlermeldungen. "Bad Gateway" und so kommen bei vielen Webseiten, die NGINX nutzen. Was bedeutet das?

Grüße vom Planeten Deviluke!

[DrachenKaiser2]

Es bedeutet, das sich entweder der apache oder fastcgi-spwan Prozess verabschiedet hat.

[jztjhtrhgefvwedcwe]

Irgendwie nutzen alle Webseiten die fehlerhaft erstellt wurden und zudem meist noch schlecht verfügbar sind NGINX - ich sehe heutzutage etliche NGINX-Fehlermeldungen aber immer seltener Apache-Fehlermeldungen auf vielerlei Websites ... liegt das evtl. daran dass NGINX einfach nur für kleine, statische Sites gebaut wurde aber bei dynamischen mit laute Getöse versagt und Apache dasselbe im umgekehrten Sinne ist? Nööööö - is ja "der gute" NGINX, der ist unfehlbar, nieder mit dem Apache-Unterdrückungsmonopol!!!1

[nginx]

---------------
> NGINX? Das kenn ich, aber nur von Fehlermeldungen. "Bad Gateway" und so
> kommen bei vielen Webseiten, die NGINX nutzen. Was bedeutet das?

Dass diese Webseiten seine Backend-Software (PHP- und Java-Bloatware) optimieren sollen. NGINX ist ein gutes Frontend.

[Uschi12]

nginx wird afaik auch von Seiten wie studivz.net benutzt. Als kleine Seite mit wenig Anfragen würde ich das nicht bezeichnen.

[Lolllipop]

jztjhtrhgefvwedcwe schrieb:
--------------------------------------------------------------------------------
> Irgendwie nutzen alle Webseiten die fehlerhaft erstellt wurden und zudem
> meist noch schlecht verfügbar sind NGINX - ich sehe heutzutage etliche
> NGINX-Fehlermeldungen aber immer seltener Apache-Fehlermeldungen auf
> vielerlei Websites ... liegt das evtl. daran dass NGINX einfach nur für
> kleine, statische Sites gebaut wurde aber bei dynamischen mit laute Getöse
> versagt und Apache dasselbe im umgekehrten Sinne ist? Nööööö - is ja "der
> gute" NGINX, der ist unfehlbar, nieder mit dem
> Apache-Unterdrückungsmonopol!!!1


Das liegt einfach an der Unfähigkeit der Admins ;)
Youtube, Wikipedia, Youporn und teilweise Google benutzen NGINX. Und von denen sieht man sowas ja nie :)

PS: Man kann auch eigene Fehlerseiten einbinden, muss ja nicht immer die NGINX-eigene sein.

[nginxer]

Das liegt daran, dass NGINX als Reverse-Proxy fungiert; Die Meldung 502/Bad Gateway siehst du immer dann, wenn sich der gute Apache hinter NIGNX mal wieder verabschiedet hat. Demnach: Its not a bug, its a feature.

Sonst würdest du garkeine Antwort auf dein Request bekommen, so weiß du zumindest woran es lag.

Das du weniger Apache meldungen siehst liegt wohl schlichtweg daran, dass die Last vom Reverse-Proxy gebalanced (jaja, denglich^^) wird.

[elbcoast]

Wir haben sehr gute Erfahrungen mit Apache als Appserver und davor nen nginx in Verbindung mit memcached gemacht. Bottlenecks sind hier dann wirklich Platten und Netzwerkkarten.

[fwegrehtrehtrj]

> Bottlenecks sind hier dann
> wirklich Platten und Netzwerkkarten.

Die Festplatten schonmal GARANTIERT nicht weil selbst eine lahme IDE133 - Platte mehr als 40 MB/s schafft - was ungefähr das vierfache einer 100Mbit-LAN-Karte ist. WENN, dann könnten tatsächlich die NICs schuld sein aber das wäre recht unwahrscheinlich - abzüglich des TCP-Overheads, der vielen Nodes zwischen Endpunkt und Startunkt und vielen anderen Faktoren kriegt man eine einzelne (!) 100 Mbit - NIC nicht ausgelastet, man kann aber die Puffer vollspammen und dementsprechend die Queue ins All schiessen - das wäre dann aber der Dummheit des Administrators zuzuschreiben.

[sadasd]

Golem.de greift auch auf NGINX zurück..

[d2]

> Die Festplatten schonmal GARANTIERT nicht weil selbst eine lahme IDE133 -
> Platte mehr als 40 MB/s schafft - was ungefähr das vierfache einer
> 100Mbit-LAN-Karte ist.

Theorie und Wirklichkeit.

Was wenn 100 Benutzer gleichzeitig verschiedene Dateien aufrufen (was ja bei Webseiten nicht ungewöhnlich ist)... dann springt die Platte wie verrückt zu verschiedenen Bereichen, da nützen 40 MB/s nicht die Bohne.

Was immer hilft ist RAM ohne Ende (zum Cachen) und halbwegs flotte Platten (selbst velociraptor Platten sind im Vergleich zu Standard 7x00 Platten ein Quantensprung).

[HansHansHans]

fwegrehtrehtrj schrieb:
--------------------------------------------------------------------------------
> > Bottlenecks sind hier dann
> > wirklich Platten und Netzwerkkarten.
>
> Die Festplatten schonmal GARANTIERT nicht

Stimmt, bei Datenbanksystemen sind Festplatten ja nie die Flaschenhälse...

[Dre Keks]

Ich benutze lenny + apache2 + mod_php und für "alle" assets ein reversproxy varnish + lighttpd.

Rennt wie hulle! Ausfälle kann ich bisher keine verzeichnen.
der lighty hat sich am anfang mal bissl weggehängt aber nach nem packetupgrade is da auch nix mehr.

mod_pagespeed is mir noch ein bisschen zu experimentell, ich warte da noch.

[fregtrhtrjztkjztk]

> Was wenn 100 Benutzer gleichzeitig verschiedene Dateien aufrufen (was ja
> bei Webseiten nicht ungewöhnlich ist)... dann springt die Platte wie
> verrückt zu verschiedenen Bereichen, da nützen 40 MB/s nicht die Bohne.

Deswegen setzt man ja auch keine Hardware ein die theoretisch auch beim kleinen Hans unterm Kinderzimmertisch stehen könnte - ohne ein vernünftiges SAS-Array brauch man über derartige Lösungen garnicht erst nachdenken, über RAID 60 oder 5EE ist dann auch die Zugriffszeit bei rand() gross genug

> Was immer hilft ist RAM ohne Ende (zum Cachen) und halbwegs flotte Platten
> (selbst velociraptor Platten sind im Vergleich zu Standard 7x00 Platten ein
> Quantensprung).

Jo ... wobei eine gute Lösung in Bezug auf HTTP nicht vom RAM abhängig sein sollte - die Platten müssen die IO-Last tragen können, da hilft nix

[DerKeks]

> Was wenn 100 Benutzer gleichzeitig verschiedene Dateien aufrufen (was ja
> bei Webseiten nicht ungewöhnlich ist)... dann springt die Platte wie
> verrückt zu verschiedenen Bereichen, da nützen 40 MB/s nicht die Bohne.
Solange es immer die selben sind wird das auch irgendewann im cache liegen, du bekommst irgendwann nur probleme mit dem context switching, weil der webserver viel kleinscheiss zu erledigen hat.

Hier ist gut durchdachtes Web-seiten design von essenziellem Vorteil.


> Was immer hilft ist RAM ohne Ende (zum Cachen) und halbwegs flotte Platten
Das ist eine Mär. Du kommst context switching und forking nicht mit RAM alleine bei.
Hier kann man mit gut durchdachten systemen und konfigurationen viel mehr rausholen.

Du kannst einem brötchenverteiler in der bäckerei nicht grössere Hände geben und dann glauben das du mehr Kunden bedienen kannst.

[fwergrehtrjztrkj]

Rischdsch - nämlich die CPU da die Daten entweder im RAM liegen oder hocheffizient gespeichert wurden und dementsprechend schnell abrufbar sind ... wenn man eben alle Konventionen missachtet und eine DB mit 99% Frickel produziert, gänzlich ohne 3. Normalform dann .... tja - Beruf verfehlt.

[gtrhtrjtrhgrefwregerjh6t5]

Daher spinnt die Site auch so oft rum und ist saulahm ... zu manchen Jahreszeiten gibts ja sogar den kompletten Tag über Nicht-Verfügbarkeit

[HansHansHans]

fwergrehtrjztrkj schrieb:
--------------------------------------------------------------------------------
> Rischdsch - nämlich die CPU

Komisch, bei uns langweilen sich die CPUs immer :(

[DerKeks]

Natürlich tun sie das CPU hat auch nix mit Context switching zu tun.