Crawling-Budget steigern

  • Mich würde mal interessieren, wie bei euch die Durchschnittliche Dauer einer heruntergeladenen Seite ist? Ich merke gerade, dass mein Durchschnitt in den letzten 14 Tage hochgeschossen ist, was sich auch auf das Crawling der Seiten bemerkbar macht. Bin von 700-1600 auf über 2000 hoch. Und ich weiß nicht woran das liegen könnte. Ich habe in den letzten Tagen viel intern Verlinkt, aber das sollte sich doch eigentlich positiv auswirken und nicht negativ.

    Edit: Könnte es vielleicht daran liegen, dass ich bei manchen Links einen Filter eingesetzt habe, und die URL sehr lang ist und die Ladezeit mit einem Filter etwas länger dauert?

  • Zum Beispiel, wenn ich bei Kleider im Filter den Attribut "Rot" Auswähle, kommt dann nicht /kleider-rot, sondern eine längere URL. und Die Ladezeit dauert etwas länger, wenn man Filter verwendet.

  • Ach das meinst Du. Das ist Google primär egal. Was aber nicht egal ist, ist die Ladezeit. Und wenn da mit irgendwelchen Filtern oder anderen Dingen die Verarbeitung / Generierung der Seite länger dauert, ja, dann ist das ein Nachteil. Die Länge der URL ist egal. Es zählt, wie schnell die Seite geladen wird, also die Seite selbst, nicht Inhalte wie Bilder, JS etc.

    Und wenn Dein Server auf Grund der Filter länger braucht um die Seite zu generieren und auszuliefern, ja dann ist der Filter so gesehen ein Problem. Oder der Server zu langsam.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Okay, dann mach ich das weg. Weil seit dem ist es stark gestiegen. Der Server an sich ist von der Ladezeit im grünen Bereich. Nur bei gefilterten Sachen dauert es ein Tick langsamer. Hätte nicht gedacht, dass es so starke Auswirkungen hat.

    Hast du noch Tipps, wie man die Crawling-Zeit verbessern kann?

  • Das ist schwer zu sagen, denn es kommt ja auf die Seite und den Server an.

    Seite also die Größe, wenn da natürlich 5MB übertragen werden, dann ist das Mist.

    Server, der die Daten bereitstellen muss. Auch hier ist es schlecht, wenn der Server erst mal eine Gedenkpause macht, bevor er die Daten ausliefert. Das hängt aber vom Server und der Software ab. Wenn der natürlich erst mal 400ms Daten intern bearbeitet, Datenbanken eventuell langsam sind, oder andere Dienste und die Übertragung dann erst beginnt, dann ist das verlorene Zeit. Zeit die Du nicht mehr aufholen kannst.

    Im Grunde sind es ja mehrere Punkte:

    -> Request an Server -> interne Verarbeitung Apache -> Verarbeitung PHP, MySQL etc -> Start der Übertragung vom Apache -> je nach Größe unterschiedliche Übertragungsdauer.

    Für den Abruf und die Zeit zählt aber alles ab dem "Request". (DNS-Abfrage habe ich mal weg gelassen)

    Und wenn z.B. der Zugriff auf MySQL länger dauert oder die Verarbeitung von MySQL, weil gefiltert werden muss, dann sind das Wartezeiten, die in die Gesamtsumme einfließen.

    Das Problem oben liegt nicht direkt am "Filter", sondern am Server, Software und Umsetzung. Im speziellen Fall wohl an PHP / MySQL, denn dem Apache ist der Filter auch egal, für den ist das ein Request wie alle anderen auch.

    Optimieren geht also nur an den Stellen. Unter anderem auch mit Server-Caching um PHP und MySQL zu entlasten, Browser-Caching per Expires, um zusätzlich den Apache auch noch zu entlasten oder zumindest ETAG, um die Übertragung minimal zu halten. Scripte optimieren, Server-DIenste optimieren, Anbindung optimieren, auch zwischen Apache/PHP und Datenbank etc.

    Gerade beim Caching macht es einen großen Unterschied, ob ein Request reinkommt und...

    .. der Apache sagt: "Eh Browser, das hast Du schon alles, nimm das einfach"

    oder

    .. der Apache an PHP übergeben muss, PHP dann eine Anfrage an die Datenbank stellt, diese es zusammensuchen und PHP liefern muss, damit das dann die Daten an den Apache geben kann, damit der es dem Browser sendet.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Okay, danke. Ich schick die Punkte mal meinem Programmierer. Der soll da mal schauen. Schaue jetzt erstmal die ganzen interne Verlinkungen an, und mache mal so gut es geht alle Links weg, die eine höhere Ladezeit haben. Ich schreib hier dann die Tage, ob das sich gebessert hat.

  • Ok, eben die URL von Dir gefunden:

    /index.php?stoken=2DF70510&lang=0&cnid=04e229d36272186fe2e8859f72f59b7a&actcontrol=alist&cl=alist&tpl=&oxloadid=&fnc=executefilter&fname=&attrfilter%5Bc1f2893f4d70693147c0bd972ed30f4a%5D%5BPrint%5D=1&attrfilter%5Bysstartprice%5D=0&attrfilter%5Bysendprice%5D=1900

    Wenn da z.B. eine Session-ID drinnen steckt, die sich ständig ändert, dann bringt auch ein Caching nichts, denn das geht nur, wenn die URL gleich bleibt. Ist dem so, dann muss man sich die Frage stellen, ob die Session-ID immer und vor allem überhaupt erforderlich ist.

    Ansonsten primär auch die Datenbank begutachten und die Abfragen. Wo lange dauert so eine DB-Abfrage mit dem Filter. Warum dauert die so lange? Was kann optimiert werden?

    Du merkst also, das sind sehr viele Punkte, die aber alle zusammenhängen. Ohne das System zu kennen ist da eine genaue Antwort unmöglich.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Ja ist gerade ein schwieriges Thema mitzureden, da ich von Programmierung kaum Ahnung habe. Ich frag morgen mal den Programmierer, wie seine Meinung ist, wo man optimieren kann. Da ich ja jetzt weiß, wo der Grund ist und es leider nicht mein Gebiet ist.

    Danke für die Antworten.

  • So, habe endlich mal herausgefunden, um welche Seite es eigentlich geht. Bei Deiner URL oben hat die reine Seite eine Ladezeit von 1,73 Sek, also die reine Seite, kein CSS, JS oder Bilder. Und genau das ist das, was Google auch anzeigt. Davon sind 1,7 Sek vom Typ "Warten", also das ist das zwischen "request senden" und "Beginn der Antwort".

    Also als erster Ansatz: Apache
    Ist das Problem nur beim Filter und nicht bei anderen, dann scheidet der Apache aus

    Bleibt also das Script als solches, PHP und die Datenbank

    Caching scheidet aus, denn der Server cached (JS, CSS, Bilder). Die Seite selbst kann nicht gecached werden, da Session benutzt wird. Ist aber nicht so schlimm. Die Wartezeit schon. Sesson-IDs können noch dazu kommen, scheiden in meinem Test aktuell aber aus (habe es verhindert).

    Und das deutet hin auf: Schlechte Scripte, schlechte Datenbank-Abfragen (PHP-seitig), schlechte Datenbankanbindung (gerade bei Shared-Hosting) und / oder schlechte Datenbank-Konfiguration (MySql).

    Gerade bei Datenbank ist schlecht nicht immer gleich schlecht in dem Sinne. Manchmal sind da so viele Datensätze, dass das eben nicht schneller geht. In dem Fall ist dann schlicht der Server zu langsam.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Nachtrag: Hatte mich auf Deine Aussagen verlassen und falsch interpretiert. Die Seite /Damenmode/ hat eine reine Ladezeit von über 4 Sek und das wieder "warten", die anderen sind ähnlich. Problemsuche also auch beim Apache, wobei ich noch immer DB glaube,

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Die Homepage hätte ich dir auch per PN schreiben können ^^ Ich hab damals mit deutlich weniger Artikel gestartet und musste dann mehrmals den Server aufstocken. der Server ist jetzt anscheinend auch wieder an der Grenze..

    Ich habe gerade mal geschaut, was für einen Server ich habe. Das sind die Daten:
    4 CPU Kerne Intel Xeon
    8 GB RAM
    SSD Raid Festplatten
    Debian Linux 64Bit

    Frage ist jetzt, was erhöht werden soll?

  • Nachtrag: Hatte mich auf Deine Aussagen verlassen und falsch interpretiert. Die Seite /Damenmode/ hat eine reine Ladezeit von über 4 Sek und das wieder "warten", die anderen sind ähnlich. Problemsuche also auch beim Apache, wobei ich noch immer DB glaube,

    Ja sie Ladezeit erhöht sich, umso mehr Artikel geladen werden. Bei reiner Damenmode lädt der ja 60 tausend Artikel. Bei der Kategorie Cocktailkleider ist der Server um einiges schneller, weil weniger Artikel geladen werden.

  • äm, entweder bin ich nun falsch oder dein Script. Auf der Seite sind keine 60.000 Artikel, da pageniert. Wenn die da wirklich 60.000 lädt, aber gar nicht nutzt, dann ist das ein gravierender Fehler. Die Seite besteht aus einer festen Anzahl. Wenn eine höhere Anzahl an möglichen Artikeln zu Problemen führt, dann habt ihr ein Script- und / oder DB-Problem. Zudem geht es nicht um die Darstellung der Seite, sondern um den Abruf des Quelltextes.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Hab mich falsch ausgedrückt. Da werden keine 60 tausend Artikel geladen, aber was ich mich gerade frage ist, warum bei Unterkategorien schneller geladen wird, als bei der Hauptkategorie Damenmode? Wen, dann müsste doch die ganze Seite genauso langsam sein. Ist die ja nicht. Nur bei Hauptkategorien

  • Die Homepage hätte ich dir auch per PN schreiben können ^^ Ich hab damals mit deutlich weniger Artikel gestartet und musste dann mehrmals den Server aufstocken. der Server ist jetzt anscheinend auch wieder an der Grenze..

    Ich habe gerade mal geschaut, was für einen Server ich habe. Das sind die Daten:
    4 CPU Kerne Intel Xeon
    8 GB RAM
    SSD Raid Festplatten
    Debian Linux 64Bit

    Frage ist jetzt, was erhöht werden soll?

    Huch, den Post hatte ich übersehen. Das kann man so aber nicht sagen, denn das System als ganzes ist unbekannt. Ich würde hier aber auf den RAM tippen und das in Verbindung mit der Config der Dienste. Kann auch sein, dass das System viel zu groß ist, die Dienste nur schlecht konfiguriert sind. Es gibt auch Leute, die ständig die Server erweitern, obwohl das Problem die Software ist @schnellschuss.... Da kommt leider vieles zusammen, was sich aus der Ferne nicht erörtern lässt.


    Z.B. *** Link veraltet ***
    Da werden für den Kalender an die 30 Mio Datensätze durchsucht. Warten = um die 100ms und das ist langsam, da aktuelle gesonderte Prüfungen laufen.

    Umgebung:
    Debian 8.3
    2 Kerne AMD
    2 GB Ram
    SATA Software-Raid Platte

    ^^ meine Hardware ist also deutlich schlechter als Deine, aber wesentlich schneller.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(