RemoteCrawl Grundkonzept

Ideen und Vorschläge sind willkommen.

RemoteCrawl Grundkonzept

Beitragvon Phiber » Mi Nov 05, 2008 9:53 am

So ich hatte heute früh eine Idee wie man das Grundkonzept von RemoteCrawl grundlegend ändern könnte, um es sinnvoller und effizienter zu machen. Weiter könnte ich mir so eine starke Verbesserung des YaCy-Netzwerkes vorstellen und vorallem eine Crawlspeed-Erhöhung des gesamten Netzwerkes in ungeahntem Ausmass.

Im Moment werden meines Wissens wenn Peer A Links fürs Remotecrawlen zur Verfügung stellt (z.b. für Peer B), sagen wir jede Minute 20 Links an Peer B gesendet welche diese lädt und Indexiert. Das System beruht auf einer dauernden direkten Kommunikation und schneidet sich auch stark gegenseitig ein.

Darum die Idee: Warum macht man aus dem RemoteCrawlen nicht eher eine Arbeit von Job-Verteilung. Ein Peer kreiert aus seiner Crawl-Seite kleine Unterjobs, wo er nur den Header dieses Unterjobs als Auftrag in das Netzwerk weitergibt.

Also in etwa so: Peer A will amazon.com mit Tiefe 4 crawlen als RemoteJob um diesen Riesenauftrag zu verteilen. Der Peer kreiert nun aus den Anfangsseiten mehrere Jobs mit Tiefe 3 und sendet jeweils einen Jobauftrag mit StartURL, Tiefe3 und Filter an Peers welche RemoteJobs annehmen. Es reicht dazu eine einmalige Kommunikation und die einzelnen Jobs können auf den verteilten Peers als LocalCrawl effizient und schnell verarbeitet werden.

Dazu gehört dann natürlich auf den Empfänger-Peers auch, dass man eine maximale Crawltiefe einstellen kann und die Blacklist angewendet wird, sonst akzeptiert man den Job gar nicht erst.


Wie gesagt entstanden ist die Idee eigentlich rein daraus, dass ich zu unkreativ bin dauernd neue gute Diversifizierte Seiten meinem LocalCrawler zu füttern und dieser seit ner Woche eher brach liegt statt arbeitet. So wird es sicher vielen Peers gehen, wenn man die Netzwerkstatistik anschaut sind dort meist keine 10% der Peers aktiv am crawlen und ich denke von den restlichen 90% ist die Hälfte sicher kein purer DHT-Peer sondern ein brachliegender Crawl-Peer. Man könnte somit die Job-Vielfalt und auch gute Ideen für zu crawlende Sachen von engagierten Peers gut verteilen und somit den Crawlspeed und die Qualität des YaCy-Netzes enorm steigern. Ob das jetzt aber eine gute Idee war und ob es Sinn macht, weiss ich nicht, drum stelle ich das jetzt mal hier zur Diskussion ;)
Phiber
 
Beiträge: 96
Registriert: So Okt 05, 2008 9:04 pm

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Mi Nov 05, 2008 10:15 am

das sieht man mal wie weit die Bedürfnisse der Peer-Betreiber auseinander gehen: vor kurzem wurde hier noch gefordert dass Remote Crawls völlig abgeschaltet werden, und im Laufe der Diskussion habe ich dann default-Durchsätze des Remote Crawlens per parameter verringert. Wer mehr remote crawls ausführen will, kann das ohne Probleme, muss nur die Performance Einstellungen ändern.

Phiber hat geschrieben:Im Moment werden meines Wissens wenn Peer A Links fürs Remotecrawlen zur Verfügung stellt (z.b. für Peer B), sagen wir jede Minute 20 Links an Peer B gesendet welche diese lädt und Indexiert. Das System beruht auf einer dauernden direkten Kommunikation und schneidet sich auch stark gegenseitig ein.


das ist nicht so! Das Versenden von Remote Crawls ist seit ungefähr einem Jahr Geschichte. Wenn ein Peer remote Crawls ausführen will, so holt er sich die einfach von den Peers, die Links 'übrig' haben ab. Da gibt es auch kein Performanceproblem, je mehr ein Peer abholen will, desto mehr bekommt er. Die 'direkte Kommunikation' ist nur ein 'kleines' GET an den remote-crawl provider im Verhältnis 1:10 (pro 10 remote indexierten Seiten ein Zugriff auf den Provider, denn man bekommt zur Zeit immer 10 auf einmal.)

Phiber hat geschrieben:Also in etwa so: Peer A will amazon.com mit Tiefe 4 crawlen als RemoteJob um diesen Riesenauftrag zu verteilen. Der Peer kreiert nun aus den Anfangsseiten mehrere Jobs mit Tiefe 3 und sendet jeweils einen Jobauftrag mit StartURL, Tiefe3 und Filter an Peers welche RemoteJobs annehmen. Es reicht dazu eine einmalige Kommunikation und die einzelnen Jobs können auf den verteilten Peers als LocalCrawl effizient und schnell verarbeitet werden.

Das wäre ok wenn man sicher stellen kann, dass die von der ersten Seite verteilten Untercrawls disjunkte URL-Mengen haben, ansonsten machst du doppelte Arbeit, weil man kein Double-Check machen kann. Wenn man aber von der Anfangsseite weiss, es geht in viele verschiedene andere Domänen, und auf diese soll eingeschränkt werden (beispielsweise bei einem Auto-Dom-Filter 1), so könnte man es so machen. Allerdings ist dann jeder Peer mit seinem Local Crawl wiederum nicht so performant, weil er eben mit nur einer einzelnen Domain kein target-Balancing machen kann. Beim Remote-Crawling wird aber genau dieses Target-Balancing forciert. Daher wage ich mal es, es als These hinzustellen, dass auch im Falle einer Separierbarkeit der Untercrawls es performanter wäre, so vorzugehen wie wir es jetzt haben.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon bluumi » Mi Nov 05, 2008 5:54 pm

Orbiter hat geschrieben:das sieht man mal wie weit die Bedürfnisse der Peer-Betreiber auseinander gehen

:mrgreen: Du hast es halt mit dem SwissTeam zu tun, wir wollen dass unsere PCs was TUN ..

Orbiter hat geschrieben:muss nur die Performance Einstellungen ändern. Wenn ein Peer remote Crawls ausführen will, so holt er sich die einfach von den Peers, die Links 'übrig' haben ab.
Redest Du von der Einstellung "Remote Crawl URL Loader" diesen Wert habe ich schon auf 100ms gesetzt und mein Peer idelt (im Robinson) trotzdem öfters rum (~6PPM), auch wenn seine "Brüder" 800K zur Verfügung hätte
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: RemoteCrawl Grundkonzept

Beitragvon DoubleN » Mi Nov 05, 2008 8:40 pm

Orbiter hat geschrieben:das ist nicht so! Das Versenden von Remote Crawls ist seit ungefähr einem Jahr Geschichte. Wenn ein Peer remote Crawls ausführen will, so holt er sich die einfach von den Peers, die Links 'übrig' haben ab.


War wohl ne gute Idee mich mal so langsam wieder ins Forum und SVN einzulesen... scheint sich ja einiges getan zu haben seit ich weg bin :D

Dachte früher allerdings das Versenden der Remote-Crawls hatte andere Hintergründe... egal...

Gruß
NN
DoubleN
 
Beiträge: 5
Registriert: Mi Aug 15, 2007 10:15 am

Re: RemoteCrawl Grundkonzept

Beitragvon DanielR » Mi Nov 05, 2008 8:41 pm

bluumi hat geschrieben:[...] diesen Wert habe ich schon auf 100ms gesetzt und mein Peer idelt (im Robinson) trotzdem öfters rum (~6PPM)

Hast du unter Admin->Network->RemoteCrawl auch die PPM hochgesetzt? Die ist nämlich default 6 PPM!
DanielR
 
Beiträge: 395
Registriert: Di Feb 12, 2008 2:22 pm

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Mi Nov 05, 2008 10:33 pm

Ich hoffe meine Kommentare kommen nicht zu kritisch rüber, denn ..
bluumi hat geschrieben:
Orbiter hat geschrieben:das sieht man mal wie weit die Bedürfnisse der Peer-Betreiber auseinander gehen

:mrgreen: Du hast es halt mit dem SwissTeam zu tun, wir wollen dass unsere PCs was TUN ..

.. ich will ja auch das die Peers was tun! Wenn wir hier noch ein wenig nachdenken fällt vielleicht jemanden ein Grund ein, warum man für oder gegen das Versenden ganzer Bäume argumentieren kann, um zu zeigen dass die Performance dadurch steigt. Noch besser wäre es, wenn jemand einen Algorithmus zum verteilten Abarbeiten eines depth-first-search (das ist der Crawl im Prinzip, mit ein paar kleinen Ausnahmen..) mit Doublettenvermeidung präsentieren kann (Literatur?). Den, den wir verwenden habe ich mir ausgedacht und sieht das Versenden (bzw. jetzt ist es ja eine 'Abgabe) nur der Blätter des Suchbaumes vor, weil dann ein Doublettencheck vollständig geht. Bei einem Verzweigungsgrad von angenommenen 20 führt das auch dazu, das lokal eben nur ein 1/20 durchgführt werden muss, und der Rest global gemacht werden kann. Versendet man dagegen ganze Unterbäume und beachtet man den Doublettentest nicht macht man sich dann vielleicht nicht viel Freude.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Mi Nov 05, 2008 10:39 pm

DanielR hat geschrieben:
bluumi hat geschrieben:[...] diesen Wert habe ich schon auf 100ms gesetzt und mein Peer idelt (im Robinson) trotzdem öfters rum (~6PPM)

Hast du unter Admin->Network->RemoteCrawl auch die PPM hochgesetzt? Die ist nämlich default 6 PPM!

Hier mal meine Anleitung zum Pimpen:
Performance Queues -> Experten Einstellungen ->
hier gibts 2 Dinge zum Remote Crawl:
1. Remote Crawl URL Loader: das ist der Prozess, der bei allen anderen Peers rumfragt und dort Crawls einsammelt, aber nicht ausführt! Das ist der Einsammler nur. Der sammelt aber nur wenn die remote Queue leer ist. Daher könnte man hier die Delays runter setzten, beispielsweise beide auf 1000
2. Remote Crawl Job: das ist analog zum lokalen Crawlen, und wird durch die Einstellung in network gesetzt. Hier kann man für maximale Performance die idle delay auf 1000 und busy delay auf 0 setzen.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Mi Nov 05, 2008 10:48 pm

DoubleN hat geschrieben:Dachte früher allerdings das Versenden der Remote-Crawls hatte andere Hintergründe... egal...

jaaa... es gab mal eine URL-DHT. beim Versenden wurden bestimmte Targets ausgewählt, so dass man hier ebenfalls einen Doublettencheck machen konnte (fing den Fall ab das 2 verschiedene Peers die gleiche URL versenden, dann haben die den gleichen Zielpeer angefragt und der hat beim 2. 'Angebot' dankend abgeleht und sagen können das er den Link schon kennt)

Diese Funktion ist nun tatsächlich leider verloren gegangen. Will ich aber wiederbeleben, es soll eine neue URL-DHT geben und URLs die beim Remote Crawl angeboten werden sollen vor dem Versenen 'handverlesen' werden, dann ist der Doublettencheck per DHT wieder da. Aber das kommt erst noch...
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon Phiber » Do Nov 06, 2008 6:54 am

Vielen Dank für die vielen Antworten. Das mit den Doppel-URL's habe ich im ersten Moment gar nicht so stark beachtet, das ist natürlich ein grosses Problem und wird wohl sehr schwer das ganze zu lösen wenn man nicht die Linksammlung und den Doppel-Check aufm Peer macht der danach die URL's zur Verfügung stellt.

Was die Performance für das ausführen der Remote-Crawls angeht muss ich dir aber ein wenig widersprechen Orbiter. Die Anleitung zu den Performance-Einstellungen ist gut, aber daran hat man ja auch schon oft rumgespielt. Aber damit lassen sich keine anständigen Crawl-Werte erzielen, nur so 5ppm. Bei nem Local Crawl sind es 60 (unbalanced) bis 150PPM im Adminstatus. Und das geht auch bei den tiefsten Remote-Crawl Werten einfach nicht, zumindest bei mir und bei bluumi anscheinend auch nicht ;)
Mach ich da jetzt wirklich immer noch was falsch (und andere Leute erzielen super Werte), oder sind bei allen die RemoteCrawl-Werte so schlecht und ein schneller RemoteCrawler ist im moment nur Wunschdenken?
Phiber
 
Beiträge: 96
Registriert: So Okt 05, 2008 9:04 pm

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Do Nov 06, 2008 11:17 am

ich hab die Routine nochmal durchgeguckt. Da sind 2 Sachen die auffallen:
- die PPM Einstellung in Config Network setzt die Delays der Queues nicht ausreichen richtig (entsprechend Pimp-Anleitung oben)
- der Remote Loader macht nichts wenn Einträge in der Queue sind. Das kann ja nicht richtig laufen, hier muss eine Pufferzone eingerichtet werden. Hab ich geändert, jetzt sitzt die Schwelle bei 100

Weiterhin denke ich das man die Anzahl der URLs die von remote gezogen werden sollen (bislang 20) erhöhen kann, wenn man serverseitig ein Time-Out einführt, das bei schlechtem Balancing die Abfrage früher beantwortet. Das habe ich nun alles in SVN 5319 eingebaut.

Das Remote Crawling wird aber mit diesem SVN nun unterbrochen, wenn man lokale Crawls startet. Das soll es ermöglichen das man remote crawling immer an hat, aber bei einem eigenen Crawl diesem automatisch den Vorzug gibt.

Da ich aber auf meinem Notebook noch viele andere Änderungen hatte, die dabei mit raus mussten ist dieses SVN mit vorsicht zu geniessen, es kann sein das die DHT Versendung auf schwachen füssen steht. Das war halt mitten in meiner Baustelle. Hoffe es geht trotzdem (werde hier mit meinem Notebook nicht Senior).
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon bluumi » Do Nov 06, 2008 1:00 pm

DanielR hat geschrieben:Hast du unter Admin->Network->RemoteCrawl auch die PPM hochgesetzt? Die ist nämlich default 6 PPM!

Hmm.. jetzt sag blos, dass wenn ich im Robinson Modus bin dieser Wert noch immer gültigkeit hat :shock: (Der Wert ist ja im Peer-to-Peer Fenster Bereich)
Und ja, ich hatte ihn auf 600 PPM, weil ich zuvor im Peer-2-Peer modus war.

Orbiter hat geschrieben:Remote Crawl URL Loader: Der sammelt aber nur wenn die remote Queue leer ist.

Die Queue war eigentlich immer leer, oder eben grad mal 2-3 Links.
Orbiter hat geschrieben:ich hab die Routine nochmal durchgeguckt. Da sind 2 Sachen die auffallen:

Ok, dann freue ich mich auf die neuen Versionen :-D
Und ich finde es auch völig i.o. dass er nur dann remote Crawlt, wenn er keine lokalen Jobs hat.

Und noch eine Frage zur Robinson / Peer2Peer umschaltung ... Als ich die Peers im Robinson hatte, habe ich meine 3 Peers und den von Phiber ;) da eingetragen unter den "public Cluster" Zeile .. Aber trotzdem ich nun im Peer2Peer Modus zurückgekehrt bin, sehe ich beim aufstarten diese Peers, bzw ne Meldung wenn einer nicht zu erreichen war. Heisst das dass er diese ClusterPeer vielleicht noch immer "zuerst" nach Arbeit fragen tut (was ich noch recht positiv fänd) ?
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: RemoteCrawl Grundkonzept

Beitragvon Orbiter » Do Nov 06, 2008 1:45 pm

das Cluster Konzept ist nach einer Anfrage von Urban letztes Jahr entstanden, dann aber vom Konzept her von der eigenes-Netz Idee abgelöst worden. Der Code ist noch da aber offenbar hat es wenige benutzt... Es ist sicherlich möglich das hier nicht alles ganz ausgefeilt ist. Insbesondere das Remote Crawlen glaube ich habe ich da nicht mit einbezogen. DHT geht bei Robinsons ja gar nicht (lt. Definition!), da muss man sich dann auch nicht wundern das es im Cluster nicht geht. Aber es stimmt schon das eine Cluster-Definition heissen sollte, das man remote Crawls aussschliesslich beim Cluster Partner holen sollte. So weit ich das im Code sehe holt der sich aber die Crawls von allen ab.. das wäre falsch.

PS: mit svn 5320 komme ich jetzt auf 145 PPM beim remote crawlen!
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: RemoteCrawl Grundkonzept

Beitragvon bluumi » Do Nov 06, 2008 3:10 pm

Orbiter hat geschrieben:DHT geht bei Robinsons ja gar nicht (lt. Definition!),
Cluster-Definition heissen sollte, das man remote Crawls aussschliesslich beim Cluster Partner holen sollte
PS: mit svn 5320 komme ich jetzt auf 145 PPM beim remote crawlen!

Das mit DHT hab ich gelesen und hatte mir dann "so gedacht" dass ich wenn ich 10 Peers habe in einem "tournus" die Peer's nacheinander zurück in P2P versetzt hätte, damit sich diese dann mit dem "rest der Welt" austauschen... Aber eben.. Mit dem deutlich verbesserten p2p remoteCrawlen und wenn es, wie Du bemrkt hast ü100PPM erricht, kann ich leben, vorallem nochmals weniger Admin Aufwand, und inzwischen steh ich voll auf "weniger Aufwand" ..
Dann versteh ich Dich recht, dass ich Zeilen wie
Code: Alles auswählen
W 2008/11/04 19:29:30 YACY cluster peer 'BluumiOne.yacy' was not found.
W 2008/11/04 19:29:30 YACY cluster peer 'phiber.yacy' was not found.

im reinen Peer2Peer Betrieb ignorieren kann und diese keinen Einfluss mehr haben auf den p2p Betrieb, bzw das Finden eines YACY cluster peer, diesen in keiner Weise bevorzugt behandelt.
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: RemoteCrawl Grundkonzept

Beitragvon Phiber » Di Nov 11, 2008 7:24 am

Ja danke Orbiter, mit dem neuesten Release komme ich auch auf die gewünschten 20-100 PPM. Es ist mal mehr mal weniger, aber Hauptsache er macht was wenn er schon läuft. Jetzt dürfen wir nur nicht alle RemoteCrawl's wegcrawlen :D

Edit: Mist jetzt ist das eingetreten was ich befürchtet habe: Keiner hat mehr URL's fürn RemoteCrawl ;)

Ja dein Peer war anscheinend gerade nicht sichtbar für meinen. Aber auch jetzt sind es inklusive deinem nur 4 Peers, dafür schon mit kräftig Links, hab also wieder was zu tun.
Zuletzt geändert von Phiber am Di Nov 11, 2008 3:18 pm, insgesamt 1-mal geändert.
Phiber
 
Beiträge: 96
Registriert: So Okt 05, 2008 9:04 pm

Re: RemoteCrawl Grundkonzept

Beitragvon bluumi » Di Nov 11, 2008 1:26 pm

Phiber hat geschrieben:Keiner hat mehr URL's fürn RemoteCrawl ;)

Dann sieht Dein Peer wohl meinen Peer (KSBA-Yacy) nicht .. da gibts noch 140'000 remoteCrawls
Aber wenn der andere Peer mal vom Fleck (sich korrekt ausbalanciert) dann hätte der bestimmt auch noch 50k ...
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am


Zurück zu Wunschliste

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast