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

Thema wurde von Anonymous, 23. April 2021 erstellt.

  1. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Wir finden den Unterschied nicht signifikant.

    Du misst nicht das Skript, du misst irgendwas anderes. Was wäre zu klären, aber der Schluss kann so nicht aufgehen:

    Javascript funktioniert so: Du lädst ein HTML Dokument. Darin sind andere Assets wie Javascripts referenziert ("verlinkt") die der Browser dann nachlädt. Der muss ja erstmal wissen was er nachladen soll. Das Javascript von PayPal lädt man unter einer statischen Adresse, da muss nichts errechnet werden, darum ändert sich die Aufbereitungszeit für das HTML Dokument sehr nahe 0. Und wenn die sich nicht ändert, verschiebt sich die Time to first byte nicht. Und die wiederum würde auch nicht berücksichtigen, wieviel das Javascript eine Gesamtladezeit, also HTML und dann alle Asets, effizient bremst.
     
  2. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    Was soll ich sagen: Dass ist der gemessene Effekt.
     
  3. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    #103 Anonymous, 11. Mai 2021
    Zuletzt bearbeitet: 11. Mai 2021
    Hinweis:
    Ich messe gar nichts, gtmetrix misst und ich weiß auch nicht was deren Definition von TTFB ist
    Aber an der Anzeige in gtmetrix sieht man es am schnellsten und an dem Hinweis: "Reduce inital server response time".

    Ich finde rd 0,5 Sekunden Unterschied sind durchaus signifkant, wenn man ein Script lädt, dass man an der Stelle (zumindest offensichtlich für mich) nicht braucht.

    Vorgehensweise:
    gtmetrix laufen lassen => langsamer
    "Direkt zu PayPal" ausschalten
    gtmetrix laufen lassen => schneller (siehe oben)
    "Direkt zu PayPal" einschalten
    gtmetrix laufen lassen => langsamer

    Das ist der Ausschnitt aus dem gtmetrix Waterfall, erklärt das was?
    upload_2021-5-11_8-36-25.png

    Bei uns werden knapp 60% aller Zahlungen per PayPal ausgeführt. Da wir nicht wissen welcher Anteil auf "Direkt zu PayPal" entfällt, möchten wir das auch nicht einfach ausschalten.

    Kann man den Anteil von "Direkt zu PayPal" an allen PayPal Zahlungen feststellen?
     
  4. Dennis (MotivMonster.de)

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

    Registriert seit:
    22. September 2011
    Beiträge:
    30.948
    Danke erhalten:
    6.089
    Danke vergeben:
    1.078
    Beruf:
    Mann für alles :)
    Ort:
    Weilburg
    Das müsste man in analytics sehen können anhand der Klickzahlen und Klickziele von einer Seite - da geht der FLuss ja entweder zum WK durch den checkout oder eben zu PP. Da könntest sicher auch nen Funnel für erstellen.

    Das JS wird ja nicht am Start geladen sondern parallel mitten drinnen. Daher ist das für die Darstellung und TTFB eigentlich nicht relevant. Siehst ja auch das es nicht blockierend vorne ist, sondern parallel läd.

    Kunden Browser laden das ja normal auch nur 1x und nicht bei jedem Aufruf nochmal, da ja im cache normal liegt dann.

    Klar ist jedes Byte das geladen wird optimierbar wenn esicht gebracht wird, aber ob das jetzt beim 1. Seitenbesuch oder später geladen wird macht doch normal kaum einen Unterschied aus.

    Und ich würde auch stark vermuten, dass Google und Co wissen, das das JS kein abstrafungsfaktor ist, da es ja eigentlich alle Onlineshops brauchen.
     
  5. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    Ich wiederhole es noch einmal gerne:
    Dass ist der gemessene Effekt zwischen Direkt zu PayPal an oder Direkt zu PayPal aus.
    Das kann ich mit unterschiedlichen Ergebnissen in ähnlichen Größenordnungen, immer wieder reproduzieren.
    Das kann man doch nicht wegdiskutieren ...
     
  6. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Time to first byte ist klar definiert: Du sendest eine Anfrage an einen Server und wartest wie lange es dauert bis du anfängst etwas zu bekommen. Die TTFB ist vor allem für das eigentliche HTML Dokument als zwangsweise erstem, blockierenden Schritt relevant eines Seitenabrufs relevant. Bevor das eine Dokument nicht da ist, geht genau gar nichts weiter.

    Der Shop ist durchaus so gestrickt, dass er viele Dinge im Hintergrund für die Seite erzeugt, bevor erste Daten des Dokuments geschickt werden, daher gibt es auch viele Sachen, die auf diese Latenz eine Wirkung haben. Simples Beispiel: Wenn man eine Kategorie mit 300 Artikeln pro Seite anzeigen lassen will, werden beim Seitenaufruf die Eckdaten von 300 Artikeln nachgesehen. Das dauert deutlich länger, als wenn man das für 24 macht, die TTFB steigt also bei 300 Artikeln massiv und messbar an.

    Wenns aber um PayPal geht, und ob man deren Javascript einbindet, sollte das ziemlich genau 0 an der TTFB ändern, in meinen Laborshops passiert da auch genau gar nichts. Ich hab gerade nochmal 1-2 Shopbetreiber gebeten eine Vergleichsmessung in ihren Liveshops zu machen und erwarte Feedback, aber ich glaub da werden wir nichts finden. Sollte sich das bestätigen, ist deine Messung krumm oder dein Shop ein Sonderfall.
     
  7. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    @Wilken (Gambio)
    Danke für die Erklärung und den zusätzlichen Test.

    Mir geht es auch gar speziell um den Begriff "TTFB", den habe ich nur benutzt, da man den Unterschied in gtmetrix an der Stelle am ehesten sehen kann.

    Es geht darum, dass man einen (m.E. signifikanten) Unterschied in der Ladezeit feststellt, je nachdem ob der an ist oder nicht.
    Wenn man nur den Button "Direkt zu PayPal" im Artikel oder Warenkorb konfiguriert hat, braucht man den auch nur dort und sollte ihn auch dann erst laden. Wenn man Banner anzeigen will, dann meinetwegen auch noch woanders.
    Wir nutzen "Direkt zu PayPal" nur im Warenkorb, da kommen viele ja ggf. gar nicht hin, aber trotzdem haben alle das Script geladen und ggf. länger warten müssen. Schon klar, dass das nur kleiner Teil ist, der Performance ausmacht, aber letztlich besteht diese aus vielen Teilen.

    Wenn das nicht anders geht, dann ist das eben so. Aber wenn man da was optimieren kann (mit angemessenem Aufwand) sollte man das tun. Dasselbe gilt für das Thema CLS, dafür gibt es ja nun auch ein Ticket.
     
  8. Dennis (MotivMonster.de)

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

    Registriert seit:
    22. September 2011
    Beiträge:
    30.948
    Danke erhalten:
    6.089
    Danke vergeben:
    1.078
    Beruf:
    Mann für alles :)
    Ort:
    Weilburg
    Aber der TTFB ist ein definierter Wert der die Zeit von der Anfrage bis zur Antwort definiert.
    Quasi wenn ich jemanden etwas frage ist das die Zeit bis zum ersten Laut aus seinem Mund.
    Die Denkzeit wird nicht länger weil mitten in der Antwort ein Nebensatz gesagt wird oder nicht. Also das JS wird ja nicht blockierend geladen sondern parallel und bleibt dann normal im Cache des Browsers.

    Wenn dein Wert TTFB sich ändert wäre das merkwürdig.

    Meinst du die gesamte Ladezeit bis ALLES geladen ist ist das ein anderer Wert
    Oder die Zeit bis der Browser die Seite darstellt, im Hintergrund aber noch Daten läd

    Dein TTFB hängt von Leistung des Servers, Cache, DNS ab wenn ich es richtig im Kopf habe.

    Wenn eine Seite aus dem Cache kommt sollte es egal sein ob mittendrinnen noch JS parallel geladen wird.

    Die Frage ist also um welchen Messwert geht es dir wirklich?

    Und wie sehen die aus wenn z.B. im DEV vom Chrome oder Pingdom misst?
     
  9. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    Das tut er... (wenn man gtmetrix glauben schenken mag), aktull der Unterscheid eher moderat, aber war auch schon deutlich weiter auseinander. Ich checke das auch mal mit den chrome dev tools und pingdom, dauert aber ein wenig, da ich das bisher nicht so intensiv benutzt habe.

    ==
    Direkt to Paypal an
    upload_2021-5-11_13-58-59.png

    Direkt to Paypal aus
    upload_2021-5-11_13-59-28.png

    und wieder an
    upload_2021-5-11_14-6-53.png

    ein wenig gewarte und wieder aus
    upload_2021-5-11_14-21-3.png
    und wieder an
    upload_2021-5-11_14-23-47.png
     
  10. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    14. Juni 2018
    Beiträge:
    1.549
    Danke erhalten:
    228
    Danke vergeben:
    998
    #110 Anonymous, 11. Mai 2021
    Zuletzt bearbeitet: 11. Mai 2021
    Ich habe das nun auch mal getestet und doch erheblich was an Zeit rausgeholt...

    Von

    First View
    (12.031s)
    Mit PayPal Buttons

    auf

    First View
    (8.817s)
    Ohne PayPal Buttons

    (Startseite gestestet wo die Buttons oder PayPal eh keine Funktion haben / nicht zu sehen sind. Nur im Warenkorb)



    Getestet mit (Link nur für registrierte Nutzer sichtbar.)


    Ich werd den PayPal Button im Warenkorb jetzt erstmal deaktiviert lassen. Ich finde den Performance Gewinn doch beträchtlich und der Nutzen des PayPal Buttons.... na ja.

    Hatte über die Zeit auch schon einige Anrufer/Kunden die dieser Button verwirrt hat. Waren zwar nur rund 5-10 Leute aber die Dunkelziffer kennt man ja auch nicht.
     

    Anhänge:

  11. ESTUGO.net

    ESTUGO.net Mitglied

    Registriert seit:
    15. Juli 2011
    Beiträge:
    5
    Danke erhalten:
    6
    Danke vergeben:
    2
    Ich greife hier mal folgendes Zitat auf "ESTUGO ist nicht so optimal, weil es in jedem Paket eine Begrenzung der PHP-Zugriffe pro IP auf zu knappe 30 gibt" (Seite 1 dieses Threads)

    Das es bei ESTUGO eine Limitierung von 30 Verbindungen pro IP gibt ist natürlich nicht korrekt weder in der Zahl, noch in der Vermutung des Mechanismus das IP Zugriffe gezählt werden. Schönes Szenario um DoS und DDoS Angriffe im Keim zu ersticken, jedoch nicht wie wir arbeiten.

    Der einzige Kontext in dem "30" auf unseren Shared Servern relevant ist, sind die simultanen Datenbankverbindungen pro DB-User. Externe IP Adressen oder Besucher im Shop haben hiermit exakt nichts zu tun und sind nicht limitiert.
     
  12. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Ok... ich weiß jetzt auch nicht mehr gerade wie ich darauf komme, aber ich dachte gelesen zu haben, dass DrGuu Estugo-Kunde ist. Offenbar dann nicht, sorry. Habe eine entsprechende Bemerkung in meinem Post auf der ersten Seite gemacht.
     
  13. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    15. Mai 2017
    Beiträge:
    684
    Danke erhalten:
    125
    Danke vergeben:
    176
    @Wilken (Gambio)
    Gibt es schon eine Rückmeldung?