Crawl Screaming Frog impossible. A cause d'un excès de liens sortants?

[FPZ]

Bonjour à toutes et à tous,

J'ai une petite question concernant des difficultés de crawl.

- Je n'arrive pas à crawler un site avec screaming frog et la quantité de mémoire n'est pas en cause : j'ai alloué 1.5 giga à SF et l'onglet "Debug" indique qu'il reste de la RAM dispo.

- Le problème semble venir du processeur, qui est à 100 % au bout de quelques milliers d'urls et le crawl s'arrête. Un petit processeur arrive à crawler 6000 pages et un I5 arrive péniblement à crawler 12 000 urls avant de bloquer. Le site comporte 50 000 pages.

- J'ai remarqué que les pages de ce site ont un très grand nombre de liens sortants : minimum 800 liens externes par page et çà monte à 2000, 4000 voire 11 000 liens sortants sur certaines pages. La plupart de ces liens "sortants" sont internes : ils envoient vers d'autres pages du site.

Pensez-vous qu'un aussi grand nombre de liens sortants par page puisse faire planter un crawl en consommant toutes les ressources processeur?

J'ai plutôt l'habitude des problèmes de crawl liés au manque de RAM et aux pages générées automatiquement... Votre avis m’intéresse!

Merci par avance.


Fred

 

[Furtif]

et çà monte à 2000, 4000 voire 11 000 liens sortants sur certaines pages

 

[FPZ]

C'est aussi ce que j'ai pensé en voyant ça :lol:

 

[longo600]

Bonjour FPZ,

je n'ai pas testé Screaming Frog en réel sur le genre de site que tu propose, mais j'ai le même phénomène sur ce type de site avec des milliers d'url par page, lorsque j'utilise des règles regex dans ma base 4D. La roue de mon mac se met a tourner, et je doit attendre parfois très longtemps (plusieurs dizaines de minutes dans les cas extremes), mais ca ne plante pas.

Du coup, j'ai mis une valeur de temps sur le crawl des pages (puisque je crée mes méthodes programmées pour le crawl sous 4D) avec une taille mini des pages "difficile", et le domaine ainsi que les pages suivantes sont noté pour utiliser l'autre méthode d'extraction des urls. J'utilise alors une autre méthode qui ne pose plus de problème (en utilisant la commande "position" dans 4D) .

Beaucoups d'extracteur ou snifer utilisent des fichiers xml dont le langage très "verbeux" devient vite inapproprié pour crawler ce genre de site (et même de gros sites).

4D est en passe de devenir Multithreading notamment sur la commande http_get , donc je préfère utiliser mon environnement de développement a la place d'outils externes.

J'ai pour le moment deux machines qui traitent en moyenne 1 million d'URL / jour (avec extraction et indexation des données) pour le moteur Premsgo.fr , si je n'avais pas cette méthodes sur ce type de pages, je serait souvent coincé.
Hélas, il y a quelques "zozo" qui ont la main lourde sur les liens, sans se rendre compte que cela n'a aucun effet sur les algo de classement...

Vu le nombre d'algo que Google doit avoir sur chaque URL, une modif sur ce genre de site doit trouver sa finalité de changement dans les serps au bout de plusieurs mois...

Je ne crois pas que Streaming Frog te ramène la page complete et la stocke sur ton disque, tu as essayé un aspirateur de site?

 

[FPZ]

Bonjour,

Merci pour ce retour d'expérience très intéressant

En effet, Screaming Frog est plus "verbeux" qu'un outil comme Xenu, qui ne semble pas avoir de mal à crawler le site !

Enfin, Xenu arrive à crawler mais comme le site est bancal (navigation à facette, etc.) ce crawler tombe dans des pièges que Screaming Frog évite. Après quelques milliers de pages crawlées, Xenu avait déjà trouvé 1 millions d'urls...

Bref, ce n'est pas une solution et je me demande si Xenu ne supporte pas mieux la montée en charge niveau processeur justement parce qu'il fait un crawl basique, sans chercher à tenir la liste des liens sortants notamment :?:

Je vais essayer avec un aspirateur de site pour voir comment çà se passe, bonne idée.

 

[longo600]

Pour te donner une idée de la méthode que j'utilise, peut etre reproductible sur une autre base ;
J'ai une table avec les URLs, cette table (lié a la table du site) a deux champs dédiés aux urls sortantes; url-insite et url sortante (et quelqus infos dans un champ objets - date -temps- etc).

J'ai une table dédié pour toutes les urls internes du site avec seulement deux champs ; ID et un champ blob.
Ce blob contient un tableau (dans 4D variable vers blob pour stoker).

C'est un tableau trié, de toutes les urls du site. La recherche utilise la dichotomie , qui trouve très rapidement une valeur même dans un tableau de 20 millions de lignes ( https://fr.wikipedia.org/wiki/Dichotomie). L'autre avantage, c'est qu'insérer une ou des lignes dans un tel tableau est aussi beaucoup plus rapide et evite de retrier a chaque boucle le tableau.

J'ai aussi une autre table avec toutes les urls déjà crawlé, en champ objet et JSON, dont la recherche dans 4D est ultra rapide (moins de 2 millisecondes environ sur 60 millions d'urls), et par sauvegarde, une autre table des urls interdite (par robots.txt).

Enfin, j'ai une table de "queue" dans laquelle je met les urls nouvelles découverte a crawler, que le crawl réduit au fur et a mesure du crawl.

Pour le moment, je ne suis pas tombé sur des sites de plus de 10 millions de pages, et ca passe facilement, sur mon mac pro avec 36Go de ram, 4D (64 bits) n'utilise pas la moitié des 20Go que j'ai dédié.

Je ne pourrais pas faire cela avec des fichiers xml en raison des volumes trop important.

Je récap :
:arrow: crawl nouvelle page => extraction des urls de la page + ajout dans une table cette url deja crawlé
:arrow: boucle dans le grand tableau trier pour chercher si ces urls sont déjà connues
:arrow: si non connues, ajouter dans le tableau trié et ajouter ces nouvelles urls dans la table de queue si non interdites
:arrow: une fois le site fini, ranger le tableau trié dans un blob.

Tu peux peut-etre programmer cela avec un autre logiciel,ou en php, si tu en as vraiment besoin.

 

[WebRankInfo]

le pb n'est pas l'outil, mais ton site ! corrige d'abord et lance ensuite un outil...
tu ne devrais pas avoir plus de quelques centaines de liens par page (et encore c'est bcp)

 

[FPZ]

Bonjour,

C'est en effet n'importe quoi ce nombre de liens par page...

Je compte bien corriger tout çà par la suite mais j'en suis au stade où je voudrais expliquer au prospect pourquoi le crawl de son site est impossible.

D'après vos retours, je crois que la raison est assez évidente. C'est juste que je n'avais jamais vu un Screaming Frog planter par manque de ressource processeur. D'habitude c'est la RAM qui lâche en premier.

longo600 -> encore merci pour tes commentaires très instructifs