Gambio und Nginx

steht schon paar mal im Forum. Nimm Apache, sonst musst bei jedem Update schauen ob Gambio die htaccess Regeln aktualisierte und nacharbeiten...
bringt keine Vorteile

 

Wir hatten den auch und nutzen den für Wordpress Seiten auch.
Gambio hat im Labor wohl eine am laufen gehabt aber es macht einfach zu viel Aufwand das zu pflegen bei zu wenig nutzern und nutzen.
Der Shop hat viele PHP und dynamische Seiten da gewinnt man nicht genug Vorteile um den Aufwand zu betreiben.
Die rewrite Sachen sind nicht so problematisch, aber das Images on the Fly, Parameterübergabe vom SE3 usw. lauter Hürden die keiner beackern will. Nimmt man Apache hat man den Stress nicht. Steht auch in Systemangaben mein ich drinnen.

 

Nginx ist gegenüber einem aktuellen Apache bei dynamischen Inhalten (PHP) keinen Deut schneller, bei statischen Assets kann er schneller sein, da ist die mögliche Haben-Seite.
Auf der Gegenseite stehen, wenn man es nicht selbst nachbildet und abdeckt: Ausfälle von Routing URLs (und damit der API Knoten von Styleedit und REST-API), Defizite in der Datensicherheit des Shops (siehe z.B. Verzeichnissperren), keine cache-freundlichen Asset URLS und kein SEO Boost (fehlende Rewrites), Probleme beim Sprachrouting und noch ein paar Todos zu gutem Caching.

Wenn es keinen zwingenden externen Grund gibt und man kein echter Pro ist, sollte man das nicht anfassen. Da gehört einiges Know-How zu.

 

Ja, siehe meine Antwort direkt über deiner. Es geht dabei nicht um könnte geben, sondern die sind erstmal da, es sei denn man erledigt die.

 

Der Aufwand und die Pflege bei Updates. Rechnet sich einfach nicht. Man gewinnt nix sondern verliert nur. WIlken hats ja technisch nochmal genauer beschrieben, da ich mich da nicht so auskenne (mach ich lassen und hatten es ja anfangs auch versucht und dann Apache davor geschaltet weil einfach einfacher ist)

 

Der Aufwand rechnet sich für Gambio nicht, da es keine Nennenswerte Vorteile gibt, sondern nur Mehraufwand für ne Handvoll Nutzer.
Wenn eine Software für Windows ist und du willst Mac nutzen musst auch selbst Lösung finden
Ist hier nicht anders.

 

https://de.wikipedia.org/wiki/Nginx

 

Wir wissen was das ist

 

Ich denke zu dem Thema gibt es offensichtlich noch Aufklärungsbedarf.

Wer ist denn "wir"?
Wilken, Cosinus und Dennis?
Oder alle im Forum, die das hier lesen?

 

Nennenswerte Vorteile, hat Wilken ja geschrieben und dargelegt.
Wir = die die sich gegen Nginx ausgesprochen haben (sollte eigentlich klar sein)

Wer den Begriff nicht kennt sollte in der Lage sein nach einem Begriff zu Googeln
Wer es nicht kennt wirds nicht lesen.

Ja nginx hat paar Vorteile, aber im Zusammenspiel mit dem Shop bringen die keinen Gewinn, sondern kosten dich mehr Arbeit und Aufwand.

 

Grundsätzlich ja, aber es zählt das Gesamtbild. Und das ist bei Shop Einzelinstallationen ausserhalb von Massendeployments ziemlich übel.

Die Problemseite der Betrachtung:

Nginx ist aus Unzufriedenheiten mit Apache entstanden. Man wollte performanter sein. Die Lage ist nun die, dass die Nginx Entwickler Designentscheidungen getroffen haben, die aus gewisser Sicht plausibel sind, aus anderer Sicht aber grosse Probleme verursachen.

Ein Beispiel: .htaccess Dateien

Die Dinger sind eine der coolsten Errungenschaften von Apache. Man kann damit schlicht den Webserver aus dem Content steuern. Die Nginx Leute sagen das kostet Performance, und das stimmt im schlimmen Fall auch. Maßvoll betrieben ist das Performance Problem aber klein und in der Kosten/Nutzen Analyse absolut sauber. Egal wie mans dreht, die Nginx Welt muss ohne die Möglichkeit leben.
Wir bleiben im Nginx: Ohne ein zu "Steuerung per htaccess Datei" vergleichbares Feature fehlt Nginx eindeutig etwas was wir brauchen, womit wir etwas besser können als ohne. Die Steuerung des Servers aus dem Content ist ein Paxisfeature mit Nutzen, wir optimieren die Shopperformance damit für alle Kunden vor. Wir sichern den Shop damit gegen Datenklau ab. Wir machen das der bei quasi allen Hostern Dinge kann, die sonst schwierig sind, und dass ein Kunde von uns kein tiefes Fachwissen braucht um gute Performance und guten Schutz zu bekommen.
Wenn man dasselbe bei Nginx will bedeutet das, dass die zugehörigen Steuerungsregeln in die zentrale Konfiguration des Webservers eingepflegt werden müssen. Ein Fehler dort bringt bei Apache, Nginx und allen anderen Webservern gleichermassen sehr schnell alle Webseiten auf der ganzen Kiste zu Fall, das ist ein dickes Risiko. Weil es das Risiko gibt, lässt kaum ein Hoster einen Kunden überhaupt irgendwie da ran. Das heisst praktisch gibt es dann weder zentral noch aus dem Content überhaupt eine Steuerung, es gibt gar nichts.

Das kann man übersetzen in: Wir können das Ding nicht steuern, Kunden aber auch nicht. Das ist fatal.

Nehmen wir mal den Fall jemand kann da tatsächlich ran, was selten genug ist:
Wir haben dann neue Anforderungen an die Synchronisation von betriebener Shopversion und zentraler Webserverkonfiguration. Das ist in Bezug auf lauter Einzelshopinstallationen überaus ekelhaft zu managen, der Händler hat einfach mehr Trouble. Wir können mit dem Shop dann nichts ohne Arbeit für den Händler griffiges ausliefern, wir müssen eher mit Updates eine 20 Seiten extra Anleitung herausgeben was denn anzupassen ist. Unsere Kunden müssen das dann ihren Hostern beifrühstücken, ohne zu wissen was sie da eigentlich gerade genau fordern oder das überhaupt einschätzen zu können. Rückfragen im dann grösseren Zirkel aus Gambio, Hoster und Händler kommen unvollständig oder mit "stiller Post"-Effekten bei den Enden an. Alle ärgern sich grün und schwarz, Lösungszeiten fallen deutlich länger aus, das haben wir einige male angeschaut.

Es macht Sinn an der Stelle zu sagen wir supporten Nginx im Standardsupport nicht. Wer sich da unbedingt ins Knie schiessen will kann das tun, ist aber mit Vorwarnung auf sich gestellt. Die Gleichung geht nicht auf.

Eine andere Frage sind Massendeployments und grosse Händler, die individuell grössere Mengen Dienstleistungsstunden bei uns einkaufen und passende Prozesse und Kompetenzen haben, oder die Auftragsssummmen so gross sind, dass wir auch in Tiefe und sachbezogene Haftung für den Teilbereich das jeweilige Projekt gehen können. Bei dynamischen Inhalten macht man auch da kaum noch Nginx, im Assetbereich kann man ein bisschen was rausholen. Dafür bezahlt der Gegenüber dann aber auch ehrlich notabel, sonst geht das auch nicht.

Abschliessend:
Wir hatten oben schon festgehalten, dass Nginx eine Antwort auf Schwächen von Apache war. Die Apache Leute sind aber nun auch nicht vernagelt, die haben sich angeschaut was die Nginx Leute neu gedacht haben. Bei den dicken Punkten (wie concurrency Limit bei gleichzeitigen Requests, Threading Modell,...) sind mit dem Event Workern und anderen Kniffen in Apache so ziemlich alle relevanten Punkte seit einer Weile auch da. Man hat die guten Ideen übernommen. Man hat sich aber andersrum die extremistischen Nummern gekniffen, man hat keine wichtige Dinge für die letzten Milliprozente umgebracht. Der Apache ist damit der deutlich universellere, in 90% der Fälle immernoch bessere Webserver. Den empfehlen wir ausdrücklich.

Dem Kollegen Cosinus prophezeie ich, mit nicht perfekter wissenschaftlicher Genauigkeit aber doch mit sehr, sehr hoher Trefferwahrscheinlichkeit: Dein Shop läuft technisch schlechter als die meisten. Er ist hochwahrscheinlich unsicherer, er kann hochwahrscheinlich weniger, er hat hochwachrscheinlich mehr Probleme.

Überleg dir genau, was du da tust und was du kannst. Tu es nur, wenn du das Thema wirklich auf dem Kasten hast.

 

@Wilken (Gambio)

Danke für die ausführliche Begründung. So ist es doch wesentlich einfacher, sich eine eigene Meinung zu dem Thema zu bilden.