Erfahrung mit Concurrency beim Shared Webhosting

[pipkin]

Hallo zusammen,

was sind Eure Erfahrungswerte für die concurrency beim Crawlen bei mittelgroßen Paketen* beim Shared Webhosting?

Hintergrund: das Crawlen braucht aktuell 39 Minuten, es gibt aber erst einen Bruchteil der zu crawlenden Seiten (20.000 URLs). Ich habe die Crawler über die Konsole angestoßen und dabei den Wert für concurrency auf 40 gesetzt. Damit waren es schon nur noch 13 Minuten. Wenn die Website irgendwann fertig ist, ist die Anzahl der URLs um den Faktor 17 gewachsen. Rein rechnerisch brauchen die Crawler dann fast 4 Stunden.

Ich würde den concurrency-Wert daher gern noch weiter erhöhen, fürchte aber, eine Grenze zu überschreiten - und es fällt mir schwer, sie einzuschätzen.

* Zur Einordnung: mein Paket hat 25 GB SSD Webspace, 4096 MB RAM, Scriptlaufzeit 360 Sek.

[Spooky]

Sind es wirklich 20.000 URLs die überhaupt indexiert werden müssen? Welchen Wert hast du für --max-depth angegeben?

[pipkin]

Ja, leider müssen sie alle indexiert werden. Es handelt sich um News - mit jeweils sehr wenig Text-Inhalt darin, der aber über die interne Suche findbar sein muss.
Davon gibt es derzeit 20.000 Stück. Geplant sind 350.000.

Ich habe unterschiedliche Tests gemacht, damit die URLs überhaupt in einem Crawl-Vorgang erfasst werden.

Am Anfang hatte ich 10 News pro Seite mit Pagination, was zur Folge hatte, dass bei einer max-depth von 3 nur 82 URLs gecrawlt worden sind. Startseite, Liste und 8x 10 News. Der Faktor 8 entstand durch die Pagination, die den Level 3 dann sehr schnell begrenzte.

Ich habe dann die News pro Seite und auch die Suchtiefe erhöht. Bei 100/ Seite und Tiefe 40 war ich dann bei > 20.000 URLs angelangt. (Wahrscheinlich hätten auch weniger gereicht, aber ich habe mich rangetastet).
Inzwischen habe ich auch mal die Pagination raufgesetzt, dass ich mit weniger Suchtiefe auskomme.

Bei einer 5 Requests zeitgleich, brauchte der Vorgang 39 Minuten. Bei 40 waren es nur noch 13. Also Anzahl vervierfacht, Tempo aber nur gedrittelt.

Da sich die Inhalte der 350.000 News praktisch nicht ändern werden, muss der Crawl-Vorgang eigentlich auch nur einmal initial klappen. Wenn er denn 4 Stunden dauern muss, kann ich damit auch leben. Aber ich bin halt unsicher, ob der Server nicht aus irgendwelchen Gründen die Verbindung abbricht. Es ist halt nur Shared Hosting. Jedenfalls würde ich die Requests gern hochsetzen, aber ich möchte ungern geblockt werden...

[Spooky]

--max-depth=3 sollte reichen, vorausgesetzt die News Detail Seiten sind in der Sitemap erfasst.

[tab]

Ok, 350.000 Seiten sind jetzt nicht unbedingt der Regelfall, aber wir haben jetzt ja schon einige Dinge optimiert im Lauf der letzten Jahre. Angefangen mit Composer und mittlerweile ja auch einen intelligenten Public Cache. Der hat mich jetzt geradeauf die Idee gbracht, dass man das Crawling vielleicht auf ähnliche Weise optimieren könnte. Es gibt ja für den Cache die Funktonalität, dass bei Änderungen von Elementen einer Seite diese automatisch als nicht mehr aktuell markiert wird. Könnte man sowas mit dem Crawler nicht auch nutzen? Entweder komplett identisch oder nötigenfalls in modifizierter Form?

Dann wüsste der Crawler von jeder Seite schon vorher, ob er sie komplett neu durchsuchen und indexieren muss oder ob es reicht, die Links für die Seiten der nächsten Tiefe zu extrahieren, weil die Seite bereits indexiert ist. Im Idealfall wären auch die Links in irgendeiner (Baum-)Struktur gespeichert für jede Seite oder vielleicht alternativ aus der bereits vorhandenen Sitemap kostengünstiger erzeugt als die ganze Seite auf Links zu durchsuchen.

Wenn man da eine ähnlich geniale, optimierte Umsetzung hätte wie beim Composer und beim Seitencache, dann wären die 13 Minuten am Ende vielleicht nicht mal mehr 13 Sekunden. Bzw insgesamt vielleicht schon immer noch 13 Minuten, aber man könnte die Seiten indexieren so wie sie eben hinzugefügt werden und müsste nicht alles auf einmal am Schluss komplett durchcrawlen.

[pipkin]

--max-depth=3 sollte reichen, vorausgesetzt die News Detail Seiten sind in der Sitemap erfasst.

Die max-depth ist ja zum Glück fast wumpe, weil sie am Tempo insgesamt nichts ändert, sondern nur die Vollständigkeit der Indexierung steuert.
Die Sitemap ist ein anderes Thema... der Crawler muss leider ohne sie auskommen, denn:

Broken link! Could not request properly: Operation timed out after 10000 milliseconds with 0 bytes received for "https://mydomain/sitemap.xml".

Sie braucht zu lange.
Ist aber nicht schlimm, da ich sie eh statisch hinterlegen muss (also mehrere), da Google mit Sitemaps mit mehr als 50.000 URLs nicht arbeitet, ich muss also ein Sitemap Index File erstellen (händisch) und dann dort in einer Verschachtelung (auch nur einer, denn mehr als eine akzeptiert Google auch nicht) Unter-Sitemaps mit jeweils < 50.000 URLs dranhängen. Die Original-Sitemap von Contao wäre zu groß für Google, weil Contao nicht verschachtelt. Shopsysteme tun das, wie z.B. Shopify, weil es da normal ist, dass man zig tausend Artikel im System hat. Wäre ja doof, wenn Google nicht indexieren kann, weil die Sitemaps nicht akzeptiert werden.

Aber zurück zum Thema: das Tempo des Crawlings/ Requests...

Wenn man da eine ähnlich geniale, optimierte Umsetzung hätte wie beim Composer und beim Seitencache, dann wären die 13 Minuten am Ende vielleicht nicht mal mehr 13 Sekunden. Bzw insgesamt vielleicht schon immer noch 13 Minuten, aber man könnte die Seiten indexieren so wie sie eben hinzugefügt werden und müsste nicht alles auf einmal am Schluss komplett durchcrawlen.

Die 13 Minuten kommen ja leider schon bei 20.000 URLs zusammen (bei einer concurrency von 20). Bei 350.000 stelle ich mich auf 4 Stunden aufwärts ein.

Während meiner ganzen Tests träumte ich von einem Crawler, der das Crawling von selbst immer in Etappen anstößt, sobald nicht so viel Traffic ist auf dem Server.
Oder von einem, der immer mal in Etappen automatisch crawlt. So wie Google Bots, die crawlen ja auch nur einen Teil, dann kommen sie wieder vorbei, crawlen den nächsten usw.

Aber momentan wäre ich einfach nur froh, wenn die Crawler die 4 Stunden durchackern. Ansonsten braucht es dann wohl doch einen dedizierten Server.


Ihr habt also noch keine Erfahrung mit einem Wert für die Concurrency?

[tab]

Aber zurück zum Thema: das Tempo des Crawlings/ Requests...

Die 13 Minuten kommen ja leider schon bei 20.000 URLs zusammen (bei einer concurrency von 20). Bei 350.000 stelle ich mich auf 4 Stunden aufwärts ein.

Während meiner ganzen Tests träumte ich von einem Crawler, der das Crawling von selbst immer in Etappen anstößt, sobald nicht so viel Traffic ist auf dem Server.
Oder von einem, der immer mal in Etappen automatisch crawlt. So wie Google Bots, die crawlen ja auch nur einen Teil, dann kommen sie wieder vorbei, crawlen den nächsten usw.

Aber momentan wäre ich einfach nur froh, wenn die Crawler die 4 Stunden durchackern. Ansonsten braucht es dann wohl doch einen dedizierten Server.


Ihr habt also noch keine Erfahrung mit einem Wert für die Concurrency?

Naja, die 4 Stunden wären dann eben 4 Minuten. Anyway ... das mit dem Crawlen in Etappen wäre wohl das Beste. Wenn es nicht so viele Seiten wären, könnte man sich eventuell schon damit behelfen, jede neue Seite mal in einem separaten Inkognito-Fenster aufzurufen, nachdem sie "erzeugt", also aufrufbar ist. Wenn alle Stricke reissen, dann halt ein Server. Wenn man das nicht so oft machen muss, ist das nicht besonders teuer. Man kann ja z.B. Server mieten, die man nur bezahlen muss wenn sie auch laufen Ist der Index erzeugt, sollte man das Ergebnis doch eigentlich auf das Webhosting zurückspielen können?!?

Andere Idee ... Verstehe ich das richtig, die für das Indexieren benötigte Zeit ist nicht das eigentliche Problem, sondern nur, dass der Crawler eventuell nicht lange genug läuft um alles vollständig zu Indexieren? Wäre es eventuell eine Idee, die Seiten durch externes Crawlen für die interne Suche verfügbar zu machen? Der eingebaute Crawler ist schön, komfortabel und für normal dimensionierte Websites auch schnell genug, aber mit externen Aufrufen durch einen externen Crawler hätte man das Problem mit der maximalen Laufzeit gar nicht erst. Das könnte notfalls sogar der GoogleBot erledigen, wenn man ihm immer eine oder mehrere aktuelle Sitemaps gibt, sofern es gewünscht ist, dass die Seiten auch im Google-Index landen und nicht nur für den internen Gebrauch gedacht sind. Ansonsten kann man das mit einem "eigenen" Crawler selbst erledigen. Zur Not vom Desktop PC oder man sucht sich einen CaaS Anbieter (Crawling as a Service . Schade, leider steht das schon für Containers as a Service)

Edit: Mit Werten für Concurrency kann ich leider nicht dienen mangels einer genügend großen Website. Das dürfte auch von Hoster zu Hoster unterschiedlich sein. Eventuell auch von der aktuellen Auslastung des Webhosting-Servers.

[pipkin]

Man kann ja z.B. Server mieten, die man nur bezahlen muss wenn sie auch laufen Ist der Index erzeugt, sollte man das Ergebnis doch eigentlich auf das Webhosting zurückspielen können?!?

Genial....
Was mich auf den Gedanken bringt, ich könnte die Installation in Kopie lokal laufen lassen und die tl_search befüllen... interessant wird dann, wie groß die tl_search als csv-Export dann wird. Bei 20.000 Seiten ist sie jetzt 31 MiB groß. Hochgerechnet wären das dann 542 MiB. Natürlich noch nicht gezippt.

Nebenbei: tl_seach, tl_search_index und tl_seach_term:
- ich bräuchte tl_search und tl_search_index, oder? Was speichert die tl_search_term?

Wäre es eventuell eine Idee, die Seiten durch externes Crawlen für die interne Suche verfügbar zu machen? Der eingebaute Crawler ist schön, komfortabel und für normal dimensionierte Websites auch schnell genug, aber mit externen Aufrufen durch einen externen Crawler hätte man das Problem mit der maximalen Laufzeit gar nicht erst. Das könnte notfalls sogar der GoogleBot erledigen, wenn man ihm immer eine oder mehrere aktuelle Sitemaps gibt, sofern es gewünscht ist, dass die Seiten auch im Google-Index landen und nicht nur für den internen Gebrauch gedacht sind.

Es ist absolut gewünscht, dass die Seiten in Google landen, auch das wird noch ein Abenteuer, da Goolge ja in Etappen indexiert und es bei der Anzahl eine Frage von Monaten (mindestens) sein wird, bis alles im Index ist. Auch deswegen spielt die interne Suche eine besondere Rolle: Google ist bekanntlich zickig. Intern sollte alles findbar sein, was vorhanden ist, auf Google muss man ewig warten.
Aber wir würde man den GoogleBot für eine interne Suche überhaupt nutzen? Google direkt einbinden?

Verstehe ich das richtig, die für das Indexieren benötigte Zeit ist nicht das eigentliche Problem, sondern nur, dass der Crawler eventuell nicht lange genug läuft um alles vollständig zu Indexieren?

Jawoll! Wobei ich nicht weiß ...

durch einen externen Crawler hätte man das Problem mit der maximalen Laufzeit gar nicht erst.

Gibt es da überhaupt eine maximale Laufzeit?
Das ist ja auch etwas, was ich durch meine Lasttests bisher noch nicht rausbekommen habe: fährt der Crawler irgendwann gegen eine Wand, und wenn ja, wo steht diese Wand?
Oder arbeitet der tapfer unendlich lang weiter, solange nur die Verbindung zum Server steht, also die Umgebung stabil ist.

Erst ein Mal ist bei mir das Crawling abgebrochen, und zwar weil ich vergessen hatte, den Ruhemodus meines Rechners zu deaktivieren.
Eine weitere Gefahr ist natürlich, dass das Netz mal kurz weg ist, weil ein Telekommunikationstechniker im Schaltkasten mal wieder Drähte vertauscht oder es dem Router zu warm wird. Aber diese Dinge sollten ja auch nicht regelmäßig passieren.


Inzwischen habe ich eine Auskunft vom Hoster (Webhostone) bekommen, dass man so genau nicht sagen kann, welchen Wert ich nutzen könne. Ehrlich gesagt hab ich auch kaum was anderes erwartet, weil es ja von so vielen Faktoren abhängt. Außerdem schrieb er:

Die meisten Kunden limitieren die Crawler auch auf 5-10 parallele Aufrufe. Sollten Sie mehr parallele Aufrufe benötigen, sollte sichergestellt sein das der Crawler auf Serverantwortzeiten reagiert oder Pausen zwischen den Aufrufen einlegt.

Mhh.... reagiert er denn auf Serverantwortzeiten? Oder legt Pausen ein?

[Spooky]

Auf der Konsole hast du kein Laufzeitlimit.

Pausen kannst du mit --delay definieren (default ist 0).

[pipkin]

Auf der Konsole hast du kein Laufzeitlimit.

Pausen kannst du mit --delay definieren (default ist 0).

Herrlich... dann kann ich ja mal experimentieren mit --concurrency=25 und --delay=100000 ... das dürfte einer Zehntelsekunde entsprechen.

Keine Ahnung, ob das viel ist oder wenig oder wie oft die Pausen dann zum Tragen kommen, aber irgendwie finde ich da vielleicht einen erträglichen Mittelwert ...

[Spooky]

und --delay=100000 ... das dürfte einer Zehntelsekunde entsprechen.

--delay wird in Millisekunden angegeben. 100000 Millisekunden = 1 Minute und 40 Sekunden...

[pipkin]

Gut, dass Du das sagst...

Hier steht Mikrosekunden... ist das ein Fehler in der Dokumentation?
https://docs.contao.org/manual/en/cli/crawl/

[Spooky]

Ups, die Dokumentation hat doch recht:

Description:
  Crawls the Contao root pages with the desired subscribers.

Usage:
  contao:crawl [options] [--] [<job>]

Arguments:
  job                                  An optional existing job ID

Options:
      --queue=QUEUE                    Queue to use ("memory" or "doctrine") [default: "memory"]
  -s, --subscribers=SUBSCRIBERS        A list of subscribers to enable [default: ["broken-link-checker","search-index"]] (multiple values allowed)
  -c, --concurrency=CONCURRENCY        The number of concurrent requests that are going to be executed [default: "10"]
      --delay=DELAY                    The number of microseconds to wait between requests (0 = throttling is disabled) [default: "0"]
      --max-requests=MAX-REQUESTS      The maximum number of requests to execute (0 = no limit) [default: "0"]
      --max-depth=MAX-DEPTH            The maximum depth to crawl for (0 = no limit) [default: "10"]
      --no-progress                    Disables the progress bar output
      --enable-debug-csv               Writes the crawl debug log into a separate CSV file
      --debug-csv-path=DEBUG-CSV-PATH  The path of the debug log CSV file [default: "C:/Users/fmg/www/c413/crawl_debug_log.csv"]
  -h, --help                           Display help for the given command. When no command is given display help for the list command
  -q, --quiet                          Do not output any message
  -V, --version                        Display this application version
      --ansi|--no-ansi                 Force (or disable --no-ansi) ANSI output
  -n, --no-interaction                 Do not ask any interactive question
  -e, --env=ENV                        The Environment name. [default: "dev"]
  -v|vv|vvv, --verbose                 Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  You can add additional URIs via the contao.crawl.additional_uris parameter.

[tab]

Aber wir würde man den GoogleBot für eine interne Suche überhaupt nutzen? Google direkt einbinden?

Das mit dem GoogleBot war nur eine Idee. Einbinden müsste man da m.E. gar nichts, sondern "nur" dafür sorgen, dass Google die Seite crawlt. Im Zweifelsfall, um es etwas zu beschleunigen, über eine Sitemap. Denn nach meinem - möglicherweise veralteten - Wissensstand, wird die interne Suche auch dann befüllt, wenn Seiten aufgerufen werden. Wer die dann aufruft ist ziemlich egal, also war halt eine spontane Idee "Warum nicht den Google-Bot dafür nutzen?". Die Aufrufe können aber natürlich von überall her kommen. Vom Webserver selbst, von anderen Servern, von deinem Desktop PC, ...
Es braucht halt nur ein Programm (wie den Google-Bot oder den Contao-Crawler), das die aufzurufenden Seiten entweder durch Links findet oder aus einer Sitemap nimmt.