Je cherche un outil comme httrack (où une configuration de httrack adaptée à mon besoin).
Le décor :
je dispose d'un site proposant plusieurs millions de page. j'utilise varnish entre un proxy http et un serveur http afin de tout mettre en cache (images, css, js et surtout le html généré). Un script journalier met à jour la base de données utilisée par le site, ce qui implique une modification journalière d'environ 50% des pages. le ttl des objets en cache est positionné sur plusieurs mois (et renouvelé à chaque accès à l'object). Les pages invalidées après la mise à jour seront purgées du cache à la fin du script.
Je cherche un outil qui pourra suivre tous les liens internes du site à partir de la première page, le cache sera ainsi regénéré.
j'utilise actuellement httrack en mode spider mais je n'arrive pas à lui faire ouvrir plusieurs connexions simultanées. Il reste bloqué à 1 connexion active alors que le serveur est capable de répondre à beaucoup plus (test réalisé avec httperf).
J'ai testé harvestman mais le projet semble abandonné et crash lamentablement après quelques pages.
Suis-je passé à coté d'outils plus adaptés à mon besoin ?
# wget, curl
Posté par NeoX . Évalué à 2.
pour ne citer que ces deux là.
pour ton probleme de connexion simultanée:
soit c'est un reglage du serveur :
-- qui n'ouvrirait qu'une connexion par client/session,
-- qui filtrerait selon le useragent pour eviter d'etre ecroulé par les spiders.
soit c'est une limite dans httrack.
par contre, si tu n'es pas le propriétaire du site distant ca va etre difficile de verifier.
sinon, une question bete, pourquoi TOUT mettre en cache si
[^] # Re: wget, curl
Posté par Fabien . Évalué à 1.
Je vais essayer avec wget, je n'avais pas vu qu'il dispose d'un mode spider, mais je doute de la possibilité d'ouvrir plusieurs connexions simultanées.
Etant le propriétaire du serveur, j'ai pu vérifier que httrack n'ouvre qu'une seule connexion bien que configuré pour lever les limites (--disable-security-limits) et les options qui vont bien. Il n'y a aucun filtrage sur le useragent ni limite conn/s
Je souhaite tout mettre en cache car j'en ai la possibilité (pas mal de ram dispo sur le serveur) et surtout parce que certaines pages peuvent être assez lente à générer (à cause d'une requête sql utilisant LIMIT .. OFFSET .. sur 1 million de records).
[^] # Re: wget, curl
Posté par Fabien . Évalué à 1.
Je m'auto-réponds, ça peut toujours servir.
httrack reste le meilleur outil pour crawler une page, il parse bien les pages à la recherche de liens et maintient la liste des liens à scanner sans créer de doublon.
Par contre, je n'arrive toujours pas à lui faire ouvrir plusieurs connexions.
J'ai donc regarder du coté de curl, et j'ai découvert une classe php permettant d'exécuter plusieurs curl en parallèle ParallelCurl.
J'ai testé cette solution qui peut être intéressante, mais sur mon projet, elle met en avant un autre problème: la génération des pages n'est pas accélérée car dépendante du temps de réponse de ma base de données. J'ai donc optimisée quelques requêtes faisant des recherches dans une colonne de type tableau:
- création d'un index GIN sur la colonne cible ( tag dans mon cas )
- utilisation d'une requête de type WHERE tag @> ARRAY['%s'] , le %s est remplacé par la valeur adéquate grâce à un sprintf
Après optimisation, je peux modifier mon script de mise à jour de la db afin de lancer un curl parallèle permettant de générer les nouvelles pages dites statiques puis une purge des pages contenant une pagination et un httrach ciblant ces mêmes pages.
[^] # Re: wget, curl
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 0.
Évidemment, on peut alors lire la BD sur l'auto-satisfaction récursive.
(pour éviter un afflux de commentaires se répondant à eux mêmes :
)
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: wget, curl
Posté par NeoX . Évalué à 2.
faut peut-etre plutot optimiser les requetes, et la base de données
plutot que de dumper tout ton site web pour l'avoir en cache.
[^] # Re: wget, curl
Posté par Fabien . Évalué à 2.
Je suis bien d'accord, la base est déjà pas mal optimisée (index de différents types sur les colonnes adéquates, tuning du serveur sql ...), EXPLAIN ANALYZE est mon ami.
Voir mon commentaire au dessus, j'ai optimisé une requête faisant des recherches dans une colonne de type tableau.
J'utilise postgresql pour plusieurs raisons :
- parce que je le préfère à tout autre sgbdr
- parce que j'utilise des triggers
- parce que j'utilise tsearch
....
Il reste une chose que je n'arrive pas à optimiser, les requêtes avec LIMIT .. OFFSET .. lorsque le nombre de résultat est trop grand (jusqu'à 1 million de ligne) et je ne peux pas utiliser les CURSORS. Il me semble que ce problème est commun à tous les sgbdr, je n'ai pas le temps de faire les tests avec mysql.
Pour la mise en cache, pourquoi s'en priver si je dispose des ressources nécessaires ?
apache ne répondra jamais aussi rapidement que varnish si la page est en cache, et encore moins lorsque le trafic simultané augmentera.
[^] # Re: wget, curl
Posté par steph1978 . Évalué à 2.
@NeoX
Je pense qu'il veut dire que le serveur web peut répondre à beaucoup plus qu'une seule connexion simultanée.
Cela n'empêche pas d'avoir toutes les pages du site en cache si elles sont coûteuses à construire (base de données + construction page + etc.)
Cette étape de construction peut certainement prendre plus d'une connexion simultanée mais pas autant que en simple consultation par les vrais clients.
D'où son besoin de remplir le cache rapidement mais sans tout écrouler.
@Fabien
Wget n'a pas d'option de multi connexions ; quant à curl, il ne crawl pas.
Est ce que tu as une façon simple (mécanique) de construire la liste des url à charger (genre /page?id=) ?
Dans ce cas, tu pourrais lancer plusieurs curl/wget, avec chacun un range.
[^] # Re: wget, curl
Posté par Fabien . Évalué à 1.
C'est la méthode que j'ai retenue pour une partie des pages (celles qui contiennent une pagination).
J'utilise la classe php ParallelCurl pour gérer les commandes curl_multi .
Une boucle génère l'url de la page et la passe à parallelcul afin d'être récupérée, moyennant une limite configurable du nombre de connexions simultanées.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.