Bandbreiten-Beschränkungen für Yacy

Ideen und Vorschläge sind willkommen.

Bandbreiten-Beschränkungen für Yacy

Beitragvon PCA42 » Mi Jun 10, 2009 2:49 pm

Da das Thema im Crawler-Thread angesprochen wurde und ich das als ehemaliger WoW-Spieler nachvollziehen kann, sollten wir da dranbleiben. Denn Yacy sollte hinsichtlich der genutzten Bandbreite konfigurierbar sein.

Ich hab auch mal im Internet gesucht und was schönes gefunden: Apache Mina. Sieht aus wie das Rundum-Sorglos-Paket für TCP/IP-Kommunikation in Java. Der Funktionsumfang kann meines Erachtens überzeugen. Und warum soll man alles selbst entwickeln, wenn Lösungen vorhanden sind. Was sagen die Devs dazu?
PCA42
 
Beiträge: 621
Registriert: Mi Jan 23, 2008 4:19 pm
Wohnort: @Home

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Orbiter » Mi Jun 10, 2009 3:16 pm

bin mal durch die doku pdf slides gegangen und hab einen guten Eindruck. Sieht danach aus als wenn man gut daran wäre alle Paradigmen beim TCP IO nochmal zu überdenken, denn die haben da eine schöne concurrency-Integration. Leider ist es so, dass wir ja nun alles an http Kommunikation über den apache httpc laufen haben, und da nicht so einfach was neues reindrücken können, denn Mina wird ja zum Aufbau von Netzprotokollen verwendet, was in diesem Fall heisst, das wir das verwenden können wenn der apache httpc auch auf Mina basiert. Oder habe ich das falsch verstanden?
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon PCA42 » Mi Jun 10, 2009 3:40 pm

Schau mal auf die Doku dort zu "AsyncWeb". Das sind die Teile für Http-Client und -Server. Kann man die als Ersatz für die httpc-Bibliothek verwenden?
PCA42
 
Beiträge: 621
Registriert: Mi Jan 23, 2008 4:19 pm
Wohnort: @Home

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Orbiter » Mi Jun 10, 2009 3:58 pm

das: http://mina.apache.org/asyncweb/ ?
Aber da ist gar kein Code, nur eine Road Map, die sich allerdings sehr gut anhört. Aber das was da steht bestätigt meine These von oben: da brauch man eine ganz neue Integration. Gucke ich mir gerne an wenn die fertig ist!
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Mi Jul 15, 2009 11:10 am

Kennt ihr I2P? Dort ist eine Java-Klasse für die Bandbreitenlimitierung zuständig: http://www.i2p2.de/download.html

Hab leider noch kein Web-Interface zum Source (Monotone) gefunden.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Seitenreiter » Mi Aug 05, 2009 8:10 am

Es sollte dem Balancer doch auch sehr hilfreich sein, wenn er die zu Verfügung stehende Bandbreite kennt um eine bessere Planbungsstrategie zu entwerfen oder?
Seitenreiter
 
Beiträge: 120
Registriert: Di Jul 28, 2009 2:45 pm

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Di Feb 09, 2010 3:22 pm

*schieb*

Dass YaCy den gesamten Upload verbraten hat, hat mir eben das Surfen unmoeglich gemacht. :( I2P z.B. hat hier eigene kleine Klassen, die als FIFO "eingehaengt" werden koennen und daraueber dann maximale Bandbreite, sowie noch tollerierte Peeks sich steuern lassen.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon dulcedo » Di Feb 09, 2010 4:51 pm

Du kannst versuchen deinem Router/Firewall zu sagen dass Pakete vom YaCy-Port oder IP mit weniger Priorität behandelt werden
(QoS). Das wird oft für Spiele oder VoIP so gemacht damit Schuss oder Sprache garantiert ankommen und sollten die meisten Home Router und natürlich ein Linux-Router können.
Port-Auswahl funktioniert allerdings nicht für den Traffic den der Crawler erzeugt, das geht nur über die IP. Hier muss noch was gemacht werden um YaCy auch aus anderen Gründen eine von mehreren Geräte-IPs zuordnen zu können, für Crawler und httpd getrennt.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Di Feb 09, 2010 5:00 pm

Und es waere doch viel einfacher - fuer den User - die Bandbreite bei YaCy wie es bei I2P und vielen anderen Peer-2-Peer-Software moeglich ist einfach einstellen zu koennen und gut ist. ch haette es ja gemacht, aber der Quellcode von YaCy ist so undursichtig und komplex, dass ich damit nicht klarkomme. :(
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon dulcedo » Di Feb 09, 2010 6:20 pm

In dem Fall ist es ja dann einfacher es von aussen zu beschränken, wesentlich einfacher ;-)
Aber eine sauber IP-Trennung muss möglich sein, YaCy greift sich je nach BS mehr oder weniger zufällig eine der möglichen WAN-IPs. Im Normalfall die erste aber das muss nicht die richtige/gewünschte sein. Auf einer Maschine ohne vhosts ist sie es ziemlich sicher nicht.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Di Feb 09, 2010 6:33 pm

Ist meiner Meinung nach sehr schoen einfach: (I2P)
screenshot-20100209_1830.png
I2P Bandwidth Limiter
screenshot-20100209_1830.png (48.96 KiB) 3653-mal betrachtet

... als dass ich (Debian System mit zwei Karten) nicht schon wieder irgentwas basteln muss. :) Einfach wie beim DynDNS-Client alles aus einer Hand bzw. einem Interface.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Di Feb 09, 2010 6:38 pm

Wenn der aktuelle Apache http Client das kann, wäre das ein Argument zu aktualisieren.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Di Feb 09, 2010 6:45 pm

Der ist hier aussen vor. Der von YaCy verwendete ist einfach zu alt und oll. :) Und da bastle ich auch dran.

Nein, ich schaetze, das wird nicht mit dabei sein. Da muesste YaCy schon etwas eigenes wie z.B. I2P das hat haben.

Hier mal eine alternative Klasse als I2P (was wohl zu spezifisch ist):
http://teaching.cs.uml.edu/Texts/OReill ... h08_04.htm
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Mo Jan 10, 2011 8:21 pm

Noch eine Idee:
wenn wir schon keine Kontrolle über den Upload haben, kann ja der empfangende Peer durch verzögerte Bestätigung die Bandbreite begrenzen. Sofern wir darüber Kontrolle haben.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Di Jan 11, 2011 4:55 am

Dan hast du bei ohnehin langsamen Verbindungen eventuell Timeouts. Und wieso etwas ausbremsen, wenn eine Dekorierer-Klasse geschrieben werden kann, die die Input- und Output-Streams dekoriert und dabei den Datendurchfluss (allgemeiner somit) ueberwacht und ihn evtl. dann bremst?
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Di Jan 11, 2011 8:39 pm

Ich sehe nicht, dass wir in absehbarer Zeit den http-Client u. Server wechseln werden. Wo soll diese Dekodierklasse ansetzen? Wo gebremst wird ist doch quasi egal, Hauptsache es gibt Kontrolle über den Upload. Manchmal werden echt fette Brocken hochgeladen wenn es mir gerade nicht passt.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Orbiter » Di Jan 11, 2011 11:00 pm

kleiner Einwurf von mir: beim http server liebäugele ich ein wenig mit jetty und probiere da auch hin und wieder was. Aber das ist wohl für das Bandbreitenthema nicht so relevant, da geht es ja wohl eher um den inbound traffic.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Mi Jan 12, 2011 9:31 am

Ja, für den Server wäre es Inbound-Traffic. Gedrosselt wird dann beim Empfänger. Ist zwar etwas komplizierter weil der sendende Client dem Server mitteilen muss wie schnell er senden möchte. Aber mit dem Apache http-Client ist es ja scheinbar nicht realisierbar.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Mi Jan 12, 2011 1:33 pm

Sende doch einfach weniger aus. :) Da muss es doch was geben.?
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Mi Jan 12, 2011 4:47 pm

Beim Antworten hierauf ist mir aufgefallen, dass es viel komplexer ist als ich dachte. Die Links die der empfangende Peer noch nicht hat werden ja nochmal extra übertragen.
Quix0r hat geschrieben:Sende doch einfach weniger aus. :) Da muss es doch was geben.?

Da sollte es getestet werden ob in kleinen Teilen verschicken vom Prinzip gut ist.
Bsp: Limit auf 50% Geschwindigkeit gesetzt. Nun braucht bei einer Verzögerung von 1s die Übertragung weil wir nicht wirklich drosseln können 0.5s. Zu testen wäre ob sich die 0.5s Auslastung nachteilig auswirken. Kann ich leider nicht machen weil meine Fritzbox gutes Traffic-Shaping hat welches nicht auszuschalten geht.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon sixcooler » Mi Jan 12, 2011 6:04 pm

Hallo,

mit Bandbreiten-Beschränkung hatte ich mich, zu mindest beim Client, auch schon
mal beschäftigt.
Meine Erkenntniss dabei war das es eher kontraproduktiv ist, die Bandbreite
bereits bestehender Verbindungen zu drosseln. Denn je länger eine Übertragung
dauert, desto höher ist das Risiko das irgendetwas in die Hose geht und
Verbindungsleichen z.B. SoHo-Router 'verstopfen'.
Die Komprimierung von DHT hat hier enorm was Verbessert.
Überhaupt ist die Menge der Verbindungen nicht zu vernachlässigen.

Derzeit ist das DHT-delay das effektivste Mittel Volumen (out) zu reduzieren.
Solange die DHT-Happen nicht zu groß sind langt dieses für mein Empfinden auch.
Nur die schon oben erwähnten, manchmal anstehenden, dicken DHT-Brocken vermiesen
wohl noch die Geschichte.

Könnte man hier nicht ansetzen?
Wenn ich das richtig im Hirn habe werden die 'DHT-Packete' zu einer
Maximal-Wortanzahl 'geschnürt'.
Wie wäre es hier das Volumen begrenzend mit einfliessen zu lassen?

Sorry das ich in letzter Zeit so passiv dabei bin - bekomme einfach keine Zeit
frei geschaufelt :-(

Cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Do Jan 13, 2011 10:41 am

Hier ist mal ein etwas groesseres DHT-Paket:
Code: Alles auswählen
I 2011/01/13 10:11:53 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWP2fe4U-11'
I 2011/01/13 10:11:53 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWRfzBv7sm2'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWR8pVWWMyA'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 8 urls for word 'pTWTT-PXKTX0'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWVSQ0Vj6S7'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 2 urls for word 'pTWXI95-i7D4'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 2 urls for word 'pTWXstXgqUPG'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 16 urls for word 'pTWYso5bsp5d'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 6 urls for word 'pTWZwJwnenvt'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 4 urls for word 'pTWcRm0T01OW'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWdagMksbOH'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWhsz7Uraoo'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 2 urls for word 'pTWjJSmaf7k7'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWkPCOAHAoD'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 3 urls for word 'pTWlqmX3U-kF'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWoEAqkFcNA'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWph5v7GPB4'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 5 urls for word 'pTWqZns_h59r'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWqeRDdlzcJ'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWtPnQomhw0'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWuAfWw4MgW'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWuYVah0fHv'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 32 urls for word 'pTWvD0YXZS-j'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWvGdjX--Nu'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWv8jgFzcR8'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selected 1 urls for word 'pTWwljIgCIfn'
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER selectContainersEnqueueToCloud: selectedContainerCache was filled with 80 entries
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER splitContainersFromCache: splitContainerCache filled with 16 partitions, deleting selectedContainerCache
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key BTWwljIgCI__/0 with 80 index containers.
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key FTWwljIgCI__/1 with 80 index containers.
I 2011/01/13 10:11:54 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key JTWwljIgCI__/2 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key NTWwljIgCI__/3 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key RTWwljIgCI__/4 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key VTWwljIgCI__/5 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key ZTWwljIgCI__/6 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key dTWwljIgCI__/7 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key hTWwljIgCI__/8 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key lTWwljIgCI__/9 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key pTWwljIgCI__/10 with 80 index containers.
I 2011/01/13 10:11:55 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key tTWwljIgCI__/11 with 80 index containers.
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER Index transfer of 3 words [roxYgujyHd6r .. zox01W5I9b__] and 17 URLs to peer srmatanza-laptop:47gJZRVIaquK in 3 seconds successful (0 words/s)
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER Transfer finished of chunk to target 47gJZRVIaquK/srmatanza-laptop
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER STORE: Chunk zox01W5I9b__ has FINISHED all transmissions!
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key xTWwljIgCI__/12 with 80 index containers.
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key 1TWwljIgCI__/13 with 80 index containers.
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key 5TWwljIgCI__/14 with 80 index containers.
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER enqueueContainers: selected 9 targets for primary target key 9TWwljIgCI__/15 with 80 index containers.
I 2011/01/13 10:11:56 INDEX-TRANSFER-DISPATCHER selectContainersEnqueueToCloud: splitContainerCache enqueued to cloud array which has now 48 entries.

Vielleicht sind ein paar Zeilen zu viel dabei. Meiner Meinung nach ist es generell keine gute Idee, die Sessions auszubremsen, da dies eventuell zu mehr wartenden Verbindungen und wie sixcooler schreibt, zu "verstopften" Routern fuehren kann - auch wenn du mehr Verbindungen pro Sekunde erlaubst.

Ich glaube aber, mehr Verbindungen pro Sekunde durch ein und die selbe "Leitungskapazitaet" (kByte/Sekunde meine ich damit) ist auch nicht gerade produktiver, da dann alle Verbindungen sehr lange brauchen und deutlich weniger pro Sekunde senden, was auch zu Timeouts fuehren kann (wie die Peer darauf reagieren, sollte bekannt sein).

Natuerlich ist eine staerke Internetverbindung immer das richtige, aber manchmal mangelt es ganz wo anders, am Geld z.B. um sich eine bessere Anbindung leisten zu koennen, oder es mangelt auch mal an der noetigen Abdeckung, was z.B. in laendlichen Gegenden (auch hier in Deutschland ist das noch so) haeufiger vorkommt.

Das Programm freenet hat hier einen ganz interessanten Ansatz: Stellt man mehr kByte/Sekunde (a la Bandbreite) ein, so werden auch (bis zu einer Maximalgrenze) mehr Verbindungen gleichzeitig geoeffnet, was somit dafuer sorgt, dass jede Verbindung noch genuegend "Saft" hat - also die Daten noch relativ zuegig uebertragen werden koennen. Wie oben bereits geschrieben, mehr Verbindungen gleichzeitig ist nicht gut (wegen weniger Daten die pro Sekunde uebertragen werden koennen pro Verbindung + TCP-Overhead). Zu viel auf einmal senden macht bei z.B. Servern kaum ein Unterschied. YaCy ist aber auch daheim mit einer ADSL-Leitung ausgeruestet installiert (der besagte Geldmangel und die Netzabdeckung spielen hier eine grosse Rolle) und dort macht das schon etwas aus, ob du z.B. 10 Sekunden lang "volles Rohr" sendest (also alles, was die DSL-Leitung hergibt) oder fuer kuerzer als 1 Sekunde, Peak auch genannt).

Vielleicht kann auch erstmal nur die DHT-Paketgroesse gemindert werden, wie sixcooler es vorgeschlagen hat.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Lotus » Do Jan 13, 2011 11:06 am

Mit großen Paketen meine ich welche mit einer fünfstelligen Anzahl von Einträgen. Die kommen auch vor, eher unregelmäßig, manchmal häufiger. Der Log sieht normal aus.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon Quix0r » Do Jan 13, 2011 11:14 am

Okay, dann war das DHT-Paket also klein.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: Bandbreiten-Beschränkungen für Yacy

Beitragvon PCA42 » Do Jan 13, 2011 5:10 pm

Ich kann hier auch nur dem Vorschlag folgen, daß die DHT-Pakete und andere Werte den gegebenen Umständen angepasst werden. Man kann sicher auch alles programmiertechnisch lösen, aber diese Energie ist woanders vielleicht besser aufgehoben.

Das grundlegende Problem ist wohl, dass einige soviel wie möglich crawlen wollen und dann die Daten natürlich auch verteilt werden müssen. Und das ist mit "handelsüblichen" asynchronen DSL-Verbindung oft nicht zu gewährleisten. Steht der nächste DSL-Verteiler mal nicht um die Ecke, ist man schnell bei DSL2000 angekommen. Und das bedeutet einen Upstream von nur 224KBit/Sec. Rein kommt aber das 10-fache. Klar, durch das Indizieren werden die Datenmengen kleiner, aber die dreifache Verteilung fordert auch ihren Tribut. Und bis man über DSL2000 ein gecrawltes Gigabyte (Download-Zeit: 1,13 Stunden) hochgeladen hat, vergeht doch etwas Zeit (ca. 31,2 Stunden).

Vorschlag zur Güte: der Dialog für die Start-Einstellungen von Yacy wird ergänzt. Es sollten halt zwei Maßstäbe vorhanden sein: einer für die zur Verfügung gestellte PC-Power und einer für die verwendbare Bandbreite. Anhand dieser Start-Einstellungen können dann Vorgaben für die PPM, DHT-In-Out, Remote-Crawling etc gemacht werden. Und wenn diese Daten optimal umgesetzt werden, sollte im Zusammenspiel mit dem Resource-Observer auch ein stabiler, langlebiger Peer entstehen.
PCA42
 
Beiträge: 621
Registriert: Mi Jan 23, 2008 4:19 pm
Wohnort: @Home


Zurück zu Wunschliste

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron