Crawling-Budget steigern

Na, ein Fazit habe ich auch nicht wirklich. Das muss Dein System-Admin wissen. An der SW lässt sich also nichts ändern, an der DB-Strukur auch nicht. Bleibt aber noch die DB an sich. Und die Caches der DB, das Filesystem, die Tabellenerstellung etc. Das muss aber Dein Admin wissen, denn der kennt ja das System. Im Notfall einfach Serverleistung erhöhen, aber die Handbremse auf zu machen ist meist besser.

Anschließend am besten alle Bilder einmal durchklicken, insbesondere die mit hohem Rotanteil. Da kann nämlich ein ganz schöner Matschhaufen bei rauskommen.

Zitat von Scheroxx

Habe gerade ein Modul von meinem Hoster entdeckt, der die Produktbilder in der Datenbank komprimiert. Laut der Beschreibung werden die Bilder 25% kleiner. Werde das mal ausprobieren und schauen, ob sich die Ladezeit verbessert.

Die Ladezeit wird sich verkürzen, aber die der ganzen Seite. Da geht es nicht um den Zugriff auf den DOM, also ist das bei Google in der Messung egal, jedenfalls was die WMT betrifft.

Aber ehrlich gesagt, Bilder gehören normalerweise nicht in eine Datenbank, dafür ist die nicht gedacht und letztendlich zu langsam.

Geht es hier um Crawling Budget?
Das geht bei grossen Seiten nur mit schneller Response. Spreche da aus Erfahrung

Hmm. Das kann viele Ursachen haben. Läufts denn schneller?

Wegen der internen Verlinkung, mach das nach cleverness. Was will man nach oben spülen und nicht was lädt am schnellsten, ist aber evtl unrelevant...

Deswegen.. es kann verschiedene Ursachen haben. Was sagen denn die WMT? Also Crawling Geschwindigkeit? Ansonsten ... bin ich jetzt im Weekend Modus. Auf nach Bertingen

Puh. Das ist heftig. Wie liegt er denn jetzt? Unter 100ms?

Hmm wegen dem Hohschiessen würde ich mir keine Sorgen machen. Ich finde die Ladezeit nicht so gut. Bei mir ist das bei reinen PHP Anwendungen mit DB ca 100ms, dort gibt es auch Hoch und Tiefs die normal sind. Wichtig ist der Durchschnitt ( eigentlch das andere auch )...

Bei Joomla ohne Cache liegt das bei ca 600ms, mit Cache unter 300ms. Das ist dann aber schon ein wenig Aufwändiger. Wenn ich da 2000 ms sehe ist das eigentlich schon zu viel. Ursachen können das einige sein.

DB bspw. Server Auslastung, Anbindung, Requests ( obwohl ich glaube das die bei den WMT aussen vor sind ). Es geht sich nur um die Crawling Geschwindigkeit. - Dann das Budget, klar.

Es könnten auch Programmierfehler ( Schleifen bspw ) dafür verantwortlich sein direkt im PHP. Wie ist denn das bei euch anderen bei der Crawl Time WMT?

Naja, also Schwankungen sind schon normal, aber nicht solche. Mal 50 bis 100ms hoch oder runter passt, aber nicht 1000-1500ms hoch oder runter.

Wie schon ganz am Anfang erwähnt, tendiere ich zur Serverkonfig mit Schwerpunk in den Bereich Datenbank. Die Ramdisk wird nicht viel gut machen, wenn überhaupt was. Was soll die auch bringen? Die TMP-Dateien werden einmal erzeugt und dann gelesen, das ist ja der Sinn davon. Und lesen von der HDD ist nur wenige ms langsamer als aus dem RAM, also wird es da nicht viel bringen. Könnte sogar nach hinten los gehen, denn der RAM steht dem normalen System nicht mehr zur Verfügung.

Wobei das mit Serverconfig natürlich so nur schwer zu sagen ist. Du nanntest Deine Serverdaten, aber das bringt auch nichts, wenn man die Config und aktuellen Leistungswerte nicht kennt. Du sagtest 4GB RAM. werden die überhaupt komplett benutzt? Ist es vielleicht zu wenig? Physisch zu wenig oder evtl zu wenig, weil die Config von den 4 vielleicht nur 2 nutzt? Was wird genutzt, für was? Du merkst, das sind alles Fragen über Fragen.

Dann hattest Du was von langsamen Kategorien gesagt, die Du nun wieder aus der Navigation entfernt hast. Sind diese Seiten denn noch aufrufbar, nur nicht verlinkt? Wenn ja, dann bringt das nichts. Wenn Google die Adressen kennt, dann ruft es die auch auf, egal ob die verlinkt sind oder nicht.

Entfernen heißt wirklich entfernen und nicht nur den Link beseitigen.

Ich würde in Deinem Fall mal alles genau testen, Stück für Stück. Angefangen mit "Abruf wie durch den Google-Bot" und das für Startseite, eine Hauptkategorie, eine Artikelseite, eine der langsamen Kategorien, einer Textdatei (z.B. robots.txt oder anderem Testfile), eine reine PHP-Datei ohne Datenbankanforderung (z.B. phpinfo()) und für ein Bild, das ja, wie Du sagst, aus der DB kommt, also PHP auch beteiligt ist.

So hast Du dann auch Werte, wie lange das jeweils dauerte und eben getrennt nach Seiteneigenschaften / Anforderungen.

Wenn das durch ist, dann einen Benchmark fahren mit den gleichen Zielseiten. Langsam anfangen und dann steigern und sehen, wann der Server in die Knie geht.

Rein theoretisch könnte es was ganz einfaches wie ein Userlimit sein, z.B. Apache oder Datenbank. Wenn da z.B. die DB auf 30 steht und Timeout 60 Sek, dann Wartet User 31 so lange, bis entweder ein Platz frei wird oder der Timeout kommt. Selbiges auch beim Apache.

oder oder oder eben, aber ohne mal anzufangen und die Daten einzeln und strukturiert auszuwerten bringt das nichts.

Jetzt aktuell würde ich sogar sagen, dass der Apache auf jeden Fall ein Problem hat, wenn aber auch vielleicht nicht alleine.

Ich gehe mal davon aus, dass das File /out/zoxidflat/src/js/libs/jquery.min.js rein statisch ist und nicht irgendwie per ModRewrite umgemodelt wird und aus der DB kommt oder so.... Wenn statisch, dann sind die Ergebnisse alles andere als gut.

DNS-Auflösung: 0ms (perfekt)
Verbindungsaufbau: 31ms (perfekt)
Senden: 0ms (perfekt)
Warten: 457ms (katastrophal)
Empfangen: 1ms (perfekt)

Dein Apache nimmt die Anfrage vom Browser also zeitnah entgegen (31ms) und empfängt dessen Daten (0ms). Nun muss der Browser aber 457ms warten, bis der Apache mal mit der Übertragung beginnt. Diese dann dauert selbst nur 1ms.

Das "Warten" ist viel zu lang. Und Deine Startseite, bei der PHP und Datenbank beteiligt sind, hat aktuell eine "Wartezeit" von fast 1,3 Sekunden.

Datenbankaktionen wie Löschen können die Seite temporär langsamer machen. Aber auch andere Datenbank Sachen. Der Google Bot wird nicht dran Schuld sein.

Userlimit kann es natürlich sein. Evtl ne Kombi von mehreren Sachen wie Datenbank und deren Beschränkungen. Evtl sogar Apache.
Bei einem guten Monitoring weiss evtl der Hoster mehr.

"kann der Crawler diesen Timeout auch auslösen?"
Ja klar. Dem Server ist es egal, was für ein Zugriff es ist, es ist ein Zugriff und fertig. Der Server weiß ja nicht, ob das ein echter Mensch ist, ein Bot oder ein DDoS oder sonst was. Zugriff ist Zugriff.

Wobei ich nicht glaube, dass der den auslöst, denn dann würde eine Fehlermeldung kommen. Kann aber sein, dass der in der Warteschleife sitzt, weil alle Plätze belegt sind und eben noch vor dem eigentlichen Warte-Timeout eine Verbindung bekommt. Das würde z.B. ein langes "Warten" erklären.

"Kann es eventuell auch dadran liegen, dass der Crawler gerade während dem Löschen auf meiner Seite ist?"
Auch möglich, aber unwahrscheinlich oder eben nicht alleinig. Der Bot von Google ist ja den ganzen Tag unterwegs und nicht nur, wenn gelöscht wird. Mit dem Bot von Google sind aber auch noch andere Bots von Sumas unterweg, Bots von SEO-Tools, Bots von Backlinkchecker, und noch so diverse andere und natürlich die echten Besucher. Alles zählt zusammen.

Wenn es früher schneller war und jetzt nicht mehr, dann spricht das noch mehr dafür, dass alles sehr genau zu ergründen. Letztendlich könnte es auch sein, dass Dein Post am Switch / router einfach überlastet ist, was gar nicht an Dir liegen muss, sondern eventuell an einem anderen Rechner, der am gleichen Port hängt.

Das sind aber Sachen die Du erörtern musst bzw. eben alles was geht eventuell auf Deiner Seite ausschließen. Dann kannste Dich an den Hoster wenden mit dem Verdacht, dass das Problem dort zu suchen ist. Hatte ich mal mit Strato, nach 2 Wochen haben die dann akzeptiert, dass es deren Problem ist bzw. von einem anderen Kunden verursacht wurde - ich war es aber definitiv nicht, mein Server war aber auch so gut wie down.