Discussion :

[mobscene]

Je bosse actuellement sur un crawler, j'ai mon propre serveur DNS mais j'aimerai que mon crawler possède lui aussi sont propre "dns reseolver" que je vais intégrer a la lib HTTP::Async que j'ai modifier , j'ai trouvé la lib gnu/adns ici http://dotat.at/prog/adns-perl/ en perl mais je n'arrive pas a l'installer j'ai lancé makefile mais il me dit qu'il ne trouve pas perl 5 et miniperl bref je comprend rien lol

Pouvez vous m'indiquer la marche a suivre ?

mici

[pospos]

tu a aussi un mode asynchrone dans Net:NS (bgread)

[mobscene]

Ah cool je vais voir sa de suite , je veux que mon crawler passe par sont resolver intégré si mon dns tombe en rade lol

[pospos]

mais c'est un client DNS aussi en fait.
Aknd tu dis ton dns tu veux dire un serveur dns?
dans tous les cas tu a besoin d'un serveur dns, et je ne sais pas si c'est facile (ou rentable) d'en integrer un à ton programme.
la bonne solution est d'avoir un client DNS asynchrone (pour pas bloquer) et avec un bon cache (avec un LRU et une expiration), et une liste de DNS alternatifs (dans ton os) pour si l'un plante

[mobscene]

Thx Pospos, par contre chose qui n'a rien a voir heu voila j'utilise sqlite comme cache pour mon crawler seulement c'est vraiment pas performant sa prend plus de 5 mn pour enregistrer 15 000 liens j'ai codé une lib de gestion reposant sur un hash sérialisé mais par exemple si le crawler veut supprimer http://www.free.fr et que c'est http://www.free.fr/ qui est enregistré dans le hash sa marche pas j'ai aussi pensé a une file d'attente sous forme de fichier plat mais comme rien ne garantie que les liens seront crawlé dans l'ordre dans lequel ils sont dans le fichier sa marche pas non plus

donc voila je cherche une solution potable merci et désolé pour le poste hors-sujet mais sa commence a me taper sur le système

[pospos]

pour les perfs avec sqlite il faut absolument utiliser des transactions, sinon les inserts sont vraiment lent. Si tu veux un cache rapide je te conseil plutot BerkeleyDB.
Pour tes url il te faut les normaliser avant de pouvoir les comparer (avec le module URI par exemple), et aussi virer le fragment en fin d'url (apres le #).
En memoire viva ca prend pas mal de place si tu utilise une hash, mais tu peux deja gagner un peu en utilisant un md5 de l'url (voir la moitié d'un md5) à la place de l'url elle meme.
En fait je bosse exactement sur ce genre de chose depuis pas mal de temps, et on a bcp de solutions qu'on devrait bientot mettre en open source, mais ca tarde pour des raisons à la con...

[mobscene]

Hein sa m'interesse sa , j'ai encore pas mal de controles a ajouter a mon crawler pour les super serveur web mal paramétré t'indique que le crawler ne prend en charge que les fichier text/html mais vue que apache a par défaut ce type mime pour les fichiers qu'ils connais pas tu te retrouve avec un crawler qui pompe du .zip


Pour Berkeley db je vais voir sa , par contre petite préçision je n'envoie pas une simple liste a mon crawler mais un hash :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$foo = {
    'lien' => ['Status index / update',int,int,int]
 };
 
$foo->{lien}[1] =  date du dernier crawler en seconde
$foo->{lien}[2] = date dernière mise a jour de la page (last-update HTTP)
$foo->{lien}[3] = intervall pour les mises a jour (tag revisit-after )

Dans BerkeleyDB je sérialise les array avec storable pour les conserver, par contre j'utlise l'interface objet et non tie je ne trouve pas comment compter le ombre d'éléments dans la db j'ai essayé c_count() sa tourne pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/usr/bin/perl -w
use strict;
use diagnostics;
use BerkeleyDB;
use Data::Dumper;
use Storable;
 
my $m = new BerkeleyDB::Hash
           -Filename => 'Queue.db',
           -Flags    => DB_CREATE,
        or die 'Unable to open file';
 
 
 
$m->db_put('red', 'apple');
$m->db_put('red0', Storable::nfreeze(['apple','maison']));
 
 
  my $cursor = $m->db_cursor() ;
 my  $status = $cursor->c_count();
 
 print $status;

[pospos]

c_count permet de compter le nombre de valeurs pour une clées donnée (duplicas).

stocker chaque url dans une hash sur disque presente qq desavantages: à terme chaque accès à ta base va resulter en un accès disque, soit environ 10ms, et ca va dopnc limiter ton crawler à 100p/s rien qu'à ce niveau.

Le mieux est d'essayer de garder toutes les structures en accès aleatoire en RAM, et ne conserver sur disque que les structures en acces sequentiel.
Pour faire ca il faut decouper ton probleme en morceau gerables en memoire.

Exemple d'approche: chaque crawler ne s'occupe que de certaines url, toujours les meme et jamais les autre. Par exemple en fonction d'une signature de l'url (par exemple un CRC32 modulo le nombre de crawler). Toute url trouvée ne conrespondant pas à la signature prise en charge par le crawler est reportée (par exemple inserée dans un fichier, ou en insert delayed dans un mysql) et eventuellement prise en charge par qui de droit.

Si tu n'a qu'un seul crawler ca te permet au moin s de prendre ces morceaux un par un. Genre tu divise ton champs d'url en 32 morceaux (avec un crc32%32) et tu les fais les uns apres les autres (en scannant à chaque fois le fichier d'ul pour prendre els url correspondtant à la signature du crawler en cours pour les gerer en ram) en tournant jusqu'à ce que tous soient vide pour un tour complet. Ansi ton crawler n'aura jamais à gerer en memoire plus d'1/32eme de ce dont il aurait besoin pour tout gerer.