Übermässiger Verbrauch von Serverressourcen (Apache - Simultane Verbindungen pro IP-Adresse)

Thema wurde von Anonymous, 23. April 2021 erstellt.

  1. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    14. Juni 2018
    Beiträge:
    1.549
    Danke erhalten:
    228
    Danke vergeben:
    998
    #1 Anonymous, 23. April 2021
    Zuletzt bearbeitet: 23. April 2021
    Übermässiger Verbrauch von Serverressourcen (Apache - Simultane Verbindungen pro IP-Adresse)

    Daten:
    -> Gambio Version: v4.2.1.0 / Malibu Theme / Dedizierter V-Server 8 CPU, 24 GB RAM <-
    PHP (7.4.16) - Aktuelle Apache-Version 2.4.46 - MySQL-Version: 5.7


    Hallo Leute
    Ich habe leider schon öfter festgestellt, das unsere Shop Seite teilweise fehlerhaft geladen wird beim Erstaufruf. Die Seite erscheint dann komplett ohne Layout.

    Der Grund wohl:
    Es wird ein HTTP 503 (Service Unavailable) Fehler vom Server produziert und die "main.min.css?bust=1617230025" wird nicht korrekt ausgeliefert. Dadurch erscheint der Shop völlig zerschossen und ohne Layout. Erst wenn man die Seite per Hand nochmal neuladet wird es richtig dargestellt.

    Habe lange nach dem Grund gesund und bin jetzt eventuell in den Apache Server Logs fündig geworden.

    Dort gibt es immer wieder folgende Fehlermeldungen:

    Das zieht sich durch und immer sind Gambio JS Dateien, CSS Dateien oder halt diese Fonts davon betroffen.

    Wir haben ein relativ starkes V-Server Hosting mit dedizierten Ressourcen.
    Der Standard Wert bei "Simultane Verbindungen pro IP-Adresse" lag bislang immer bei 30.

    In den Logs sehe ich aber das sehr oft mehr Zugriffe erfolgen. Wie oben in der Meldung z.B. 33 von erlaubten 30. Spitzenwert den ich auf die schnelle finden konnte waren 61 versuchte Verbindungen von 30 erlaubten....

    Woran liegt es das besonders beim Erstaufruf soviele simultane Verbindungen generiert werden und wie hoch sollte der Wert dann sein? Ich habe es jetzt mal auf 50 erhöht aber ich weiss nicht ob das ein Fass ohne Boden ist?

    Habt ihr vielleicht Vergleichswerte für eure Server Einstellungen? Habt ihr da deutlich mehr als 30 erlaubt?

    Danke für eure Zeit und Hilfe,


    Unser Hoster schreibt dazu in einem Beitrag:

     
  2. FRAGO

    FRAGO Erfahrener Benutzer

    Registriert seit:
    5. Dezember 2019
    Beiträge:
    1.009
    Danke erhalten:
    319
    Danke vergeben:
    185
    Magst du uns auch noch die Gambio Version verraten vom Shop?
     
  3. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    14. Juni 2018
    Beiträge:
    1.549
    Danke erhalten:
    228
    Danke vergeben:
    998
    Ups, klar: Gambio Version: v4.2.1.0
     
  4. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Das sind die einzelnen JavaScripte, die für jeweiligen Funktionalitäten bei Bedarf dynamisch und asynchron (parallel) nachgeladen werden. Dieses Verfahren ermöglicht es, dass Webseiten schnell laden. Das ist eine übliche Technik. Die serverseitige Begrenzung auf css- oder js-Dateien anzuwenden macht bei modernen Webseiten keinen Sinn und ist mit 30 viel zu niedrig angesetzt. Das hat vielleicht vor 10 Jahren Sinn gemacht, als Asynchronität im Web noch nicht so üblich war.
     
  5. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    14. Juni 2018
    Beiträge:
    1.549
    Danke erhalten:
    228
    Danke vergeben:
    998
    Oha!
    Krass.
    Danke für deinen Beitrag.

    Welchen Wert empfiehlst du dort dann einzustellen?
    Wenn 30 viel zu niedrig ist...was wäre dann optimal? 100? 200? Noch mehr?
     
  6. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Ich bin kein Serveradministrator und habe keine Ahnung, was da üblich ist. Mit 100 kommst du sicherlich erst einmal aus.
     
  7. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    #7 Anonymous, 23. April 2021
    Zuletzt bearbeitet: 23. April 2021
    Das haben wir auch!! Danke dass du der Sache auf de Grund gehst! Bei uns aber mit 4.0.3.0 und Honeygrid als Template, auf einem altmodischen All-Inkl Shared Server ("Bananenhosting" mit Max 50 Kunden für nicht mal 30 € im Monat - was will man erwarten)

    Ich frage mal bei All-Inkl. nach wie die Einstellungen sind. Ich habe mit unserem Ladezeit-Monitor auch festgestellt, dass wir mehrmals am Tag Server Response-Zeiten von bis zu 1000 Sekunden haben (also 16 Minuten!) Das wäre natürlich auch noch eine Erklärung. Wenn bloß im Plesk von Estugo die Cronjobs vernünftig laufen würden, dann könnte man tatsächlich dahin wechseln. Da müsste ja dann alles perfekt laufen, wenn das eine von Gambios Empfehlungen sind.
     
  8. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    1. September 2012
    Beiträge:
    2.422
    Danke erhalten:
    417
    Danke vergeben:
    157
    Was läuft denn nicht in den Estugo Cronjobs? Wir haben mehrere laufen, samt denen vom Shop, und funktioniert.
     
  9. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Ich hatte für einen Bekannten ein Script geschrieben, um stündlich Dropshipping-Bestände eines Lieferanten aus einer CSV in Gambio zu übertragen. 1500 EANs oder so waren das. Das Script lief bei manuellem Aufruf im Browser 1a durch und war in 6 Sekunden fertig. Als Cronjob über Estugo wurde das Script auch ausgeführt und beendet, aber nur etwa 1/3 der Artikel. Keine Fehlermeldung. Der Estugo Support hat dann noch ein paar Einstellungen umempfohlen (Ausführung der Datei oder Aufruf der URL etc.), aber das hat nichts geholfen. Am Ende hieß es, dass das Script dann wohl fehlerhaft sei und man nichts machen könnte. Warum das Script bei Direktaufruf fehlerfrei lief, aber bei Aufruf als Cronjob fehlerfrei sein sollte, ist mir nicht klar geworden. Ich habe dem Bekannten dann einen Hoster-Wechsel empfehlen müssen und bis dahin das Script über einen externen Cronjob laufen lassen - der lief 1a.

    Vielleicht auch irgendein Bug in der Plesk-Version? Oder irgendeine versteckte Server-Konfiguration die niemand am Support und auch der Geschäftsführer nicht kannte? Ich weiß es nicht. Aber doof wäre, dahin zu wechseln und dann an solchen Kleinigkeiten zu scheitern. Das hat mein Vertrauen in Estugo nicht gestärkt. Allerdings ist Estugo ja sowohl offizielle Hosting-Empfehlung von Gambio und zusammen mit All-Inkl. die reflexartige Antwort vieler Gambio-Forenuser auf die Frage, welcher Hoster gut ist.
     
  10. Dennis (MotivMonster.de)

    Dennis (MotivMonster.de) G-WARD 2013/14/15/16

    Registriert seit:
    22. September 2011
    Beiträge:
    30.947
    Danke erhalten:
    6.088
    Danke vergeben:
    1.076
    Beruf:
    Mann für alles :)
    Ort:
    Weilburg
    aufruf über externe cronjob.de oder so versucht? Kostet doch nix und ist auch flexibel einstellbar. Nur so, wenns nur an dem Punkt scheitern sollte.
     
  11. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    1. September 2012
    Beiträge:
    2.422
    Danke erhalten:
    417
    Danke vergeben:
    157
    An der Zeit kann es nicht liegen. Wir haben per CJ zwei Backups laufen und senden diese nach Ausführung an unseren FTP Server. Das dauert auch 15+ min.
     
  12. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Ja externe Cronjobs gingen, kein Problem. Aber ein kostenloser Anbieter ist für mich keine verlässliche Lösung. Und es erweckt in mir kein Vertrauen in ESTUGO, wenn so was Grundlegendes nicht geht (oder ging?)
     
  13. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    @DrGuu wo genau hast du denn die Fehlermeldung gefunden?
     
  14. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    14. Juni 2018
    Beiträge:
    1.549
    Danke erhalten:
    228
    Danke vergeben:
    998
    In den Server Logs bei unserem Hoster. Diese kann ich über eine praktische Weboberfläche direkt erreichen.
     
  15. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Server Logs gibts bei All-Inkl. nicht für Kunden. Die haben aber reingeschaut und bei uns nichts gefunden. Sie sagen, dass es auf keinem Server irgendwelche Beschränkungen zu gleichzeitigen Verbindungen pro IP-Adresse gibt :-o Kaum zu glauben. Es gibt nur max. mysql-Verbindungen und max gleichzeitige PHP-Verbindungen, die ich aber nie erreicht haben soll.

    Estugo hat mir auch geschrieben, dass es bei denen in allen Paketen max. 30 Connects pro IP gibt.
     
  16. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Es ist einfach die Frage, was eben bei den Connects pro IP mitgezählt wird. Wenn da statische Inhalte, wie Bilder, JavaScripte und CSS ausgeschlossen sind, ist ja alles kein Problem.
     
  17. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Also bei All-Inkl. gibt es ja keine Begrenzung, sagen die. Und ansonsten würde ich sagen, Bilder, Javascripte und CSS sind NICHT von der Zählung ausgeschlossen, sonst hätte @DrGuu dieses Problem mit dieser spezifischen Fehlermeldung vermutlich nicht...

    Kann man sowas alles denn auf managed servern selbst konfigurieren? Sonst muss man vielleicht mal einen managed server buchen und sich den mit 3-5 Gambio-Shopbetreibern teilen und die für Gambio perfekte Konfiguration erstellen. 80,- EUR für nen Managed Server mit 4 mittelgroßen Shops, das wären 20,- EUR für jeden pro Monat und würde bestimmt super laufen.

    @Moritz (Gambio) was sind denn die perfekten Systembedingungen? Könnt ihr das mal zusammenstellen, worauf es ankommt?

    • Max. gleichzeitige connects pro IP
    • Max. gleichzeitige Mysql-Zugriffe
    • Max. gleichzeitige PHP Connects
    • Empfohlene Hardware
    • Empfohlene Internetanbindung des Rechenzentrums
    • ...?
    Würde ja auch die Gambio Cloud in Erwägung ziehen, aber der fehlende FTP- und Datenbankzugriff ist ein Killer-Argument für mich.
     
  18. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    #18 Anonymous, 26. April 2021
    Zuletzt bearbeitet: 26. April 2021
    All-Inkl. sagt, dass das Limit der PHP-FPM-Slots das Problem ist. In der Folge stauen sich die Anfragen auf und der Server überlastet. Das hat aber dann mit synchronem Laden nichts zu tun, weil es da nur um die Anzahl gleichzeitiger Zugriffe geht, aber es dadurch keine länger laufende Zugriffe gibt, oder?

    Nachtrag von All-Inkl:
    "Bei allen Tarifen ist die Anzahl der Slots gleich. Auf einem Managed-Server könnten diese ohne weiteres erhöhen."
     
  19. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Zurück aus dem Urlaub geb ich auch mal meinen Senf dazu: Das was der Hoster da macht ist irgendwie halbgar finde ich.

    Führen wir mal kurz ein paar Begriffe ein:

    Statische Assets:
    Statische Assets sind Dateien, bei denen der Server nix rechnen muss, sondern die er auf Anforderung einfach aus der Leitung kloppen muss. Ein typisches Beispiel sind Bilder, da muss normal nix gerechnet werden, die schiebt man einfach aus dem Tor. Es sind aber nicht nur Bilder statische Assets, sondern auch CSS Dateien, Webfontdateien, Javascripte.

    Dynamische Assets:
    Das Gegenteil wäre der Aufruf von dynamischen Assets, also der Aufruf von zum Beispiel PHP Dateien. Das führt in dem Moment zu Rechenvorgängen auf dem Server und löst damit ganz anderen Lasten aus.

    Dos Attacken:
    Angriffe auf ansonsten nicht vulnerable Server und Seiten macht man in aller Regel über DoS Attacken, in lang Denial of Service. Das bedeutet normal man fragt gleichzeitig soviel Zeug auf einmal an, dass der Server die Last nicht bewältigen kann. Solche Anfragen schiebt man immer fleissig rein, und das wiederum führt dann dazu, dass alle Betrachter in Probleme laufen, weil die Kiste einfach nicht mehr an alle alles rausbekommt.

    Man kann gegen DoS Attacken und übermässige Beanspruchung durch einzelne Besucher sicher durch Requestlimits wie hier vorgehen. Da fragt man sich wie so eine Webseite denn normal ist, wird dann über den Daumen peilen, dass da ein HTML Dokument ist, ein paar Javascripte und wahrscheinlich ein Haufen Bilder. Weil man bei Bildern pauschal nie klarkommen wird, nimmt man die dann raus und sagt wird schon passen wenn wir den Rest pro Abrufer beschränken.

    Für eine altbackene Webseite und einfache Szenarierien kann das funktionieren, es hat aber Pferdefüße und geht nicht immer auf. Ein Beispiel:

    50 Mann sitzen mittags bei Gambio im Büro, einer schreibt "Ich bestell gleich Mittagessen bei Alfredo Tortellini, will jemand anderes mitbestellen?". Was dann passiert ist 50 Leute im Büro öffnen die Speisekarte einigermassen gleichzeitig. Wir sitzen alle hinter einem Router, alle Zugriffe kommen dann von einer einzigen Quell IP Adresse. Würde Alfredo die Requests auf 30 parallele beschränken, und eine sparsame Webseite hat 1 HTML Dokument, eine CSS Datei, 2 Javascripte und eine Schriftart sind das 5 nicht-Bild-Assets. Das Ergebnis wäre im optimalen Fall bekämen 6 Leute die Speisekarte, 44 Fehlermeldungen. Da aber vielleicht einer nur das HTML bekommt, einer nur das CSS und 2 andere nur das Javascript (das ist durchaus wahrscheinlich, der Server wüsste anhand der IP nicht welche Requests zusammenghören und von einem Nutzer sind...) wird das Ergebnis realistisch am Ende sein, dass 1-2 Leute die Speisekarte wirklich sehen können.

    Moderne Webseiten neigen ausserdem dazu ihre Assets mehr aufzusplitten als früher. Seit HTTP2 ist mehrere Requests gleichzeitig absetzen technisch massiv billiger geworden. Billiger bedeutet hier schneller, ohne viel Overhead wie Verbindungshandshakes und damit früher einhergehende Latenzen. Bei gleicher Inhaltsmenge und erhöhter Parallelität eines Abrufs erzeugt ein Besucher zwar einen höheren, dafür aber proportional auch kürzeren Lastspike, das Produkt aus Zeit und Lastgrösse bleibt gleich. Der Nutzen ist die Seite ist schneller beim Nutzer aufgebaut.

    Sowas nutzen wir aus, aber nicht erst seit kurzem, sondern schon seit längerem, das begann so pi mal Daumen mit GX 3.1.

    Was müsste ein Hoster also tun:

    Wenn er den gleichzeitigen Abruf von statischen Assets beschränken will, müsste er genauer hinsehen was alles statische Assets sind. Das sind nicht nur Bilder, sondern wie oben gesagt auch CSS, Fonts, Javascripte mit gleichhoher Wahrscheinlichkeit wie Bilder.

    Das Limit sollte auch über 30 liegen, 50-100 wären schon plausibler und würden die Wahrscheinlichkeit von Ausfällen für Nutzer schon erheblich senken.

    Wenn der Hoster seinen Server vor CPU Spikes schützen will, kann er auch die zuteilbare Last durch "teure" Inhalte beschränken. Teuer ist PHP, das macht wie gesagt immer Berechnungen auf dem Server. Die reine Anzahl der PHP Prozesse ist auch da halbgar als Indiz, weil man eine Aufgabe bauen kann, die mehr Last macht als 10 leichte parallelisiert ausgeführt. Idealerweise würde man über Methoden wie cgroups unter Linux der Kiste beibringen und sagen ein Kunde darf zum Beispiel 20% der CPU Leistung über Zeit haben, dann ist Ende. Das ist aber schon auch etwas komplex und neumodisch. Da sind viele Hoster noch nicht.
     
  20. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    #20 Anonymous, 26. April 2021
    Zuletzt bearbeitet: 13. Mai 2021
    Ja, das habe ich verstanden. Und der All-inkl.com Typ auch. Der empfiehlt, die PHP FPM Spots zu umgehen indem man Dinge auf Unteraccounts schiebt, weil die Begrenzung für jeden Account, nicht für jeden Vertrag, gilt. Kannst gratis 1000 Unteraccounts erstellen. Kann ja auch nicht im Sinne des Erfinders sein, und hilft halt auch nichts, wenn sich nichts auslagern lässt, also z.B. bei einem Shopsystem aus einem Guss. Manche Anbieter Laden daher ja Ressourcen über Subdomains.

    Fazit:
    • Manager Server sind großzügiger konfigurierbar aber für kleine Shops nicht bezahlbar
    • Cloud geht nicht wenn man vollen Zugriff braucht
    • ESTUGO ist nicht so optimal, weil es in jedem Paket eine Begrenzung der PHP-Zugriffe pro IP auf zu knappe 30 gibt - FALSCHINFORMATION! Keine Begrenzung laut Estugo.
    • All-inkl. nicht optimal wegen Beschränkung gleichzeitiger PHP-Zugriffe.
    Was ist denn bezahlbar und gut?

    Will jemand mit mir einen Manager Server teilen?