eMule MOD - Development Alles zum Thema MOD Entwicklung. Fragen, Wünsche, Ideen zu neuen Features. |
21. October 2005, 18:08
|
#1 | MODder
Registriert seit: 06.11.2003
Beiträge: 598
| Problem: Sinn und Unsinn von AutoHL's bzw. HL's allgemein.
Also hiermit eröffne ich nun die allgemeine Diskussionsrunde über für und wieder von Hardlimits generell und insbesondere in diesem Zusammenhang über AuoHL.
Sind diese denn wirklich nötig ? Wie könnte eine Welt ohne einstellbare Hardlimitwerte aussehen ? Hätte man dann nicht zwangsläufig in irgend einer Form wieder ein AutoHL ?
Oder läßt sich das komplett umgehen?
Auch zur Debatte bzw. zur Entwicklung stände dann hier noch ein Source-Cache,welchem wir nun erstmal die momentante Hardlimit Funktionsweise von Emule zu Grunde legen wollen.
MfG Max
__________________ |
| |
21. October 2005, 18:30
|
#2 | MODder
Registriert seit: 28.03.2003
Beiträge: 5.800
| Möchte nochmal da Posten, was ich im Xtreme-Thread zum Thema "cachen von Quellen" schon schrieb. Dieses Cachen ist eine Möglichkeit, trotz schnell änderndem Hardlimit ohne zusätzlichen Quellen-Anfrage-Overhead auszukommen.
Begriff "Quellen-Cache" Zitat:
es geht nicht darum die Quellen abzufragen.. dann könnte ich sie gleich in die Downloadqueue aufnehmen. Es geht darum die gefundenen (via Server/Kad/XS) Informationen (UserID, Port, ServerIP) zwischenzuspeichern. Momentan läuft es so: Du bekommst per XS 500 Quellen, brauchst aber nur 20-> 480 werden einfach verworfen. Die Idee für ein AutoHardlimit: falls ich 5 Minuten später neue Quellen braucht, nutze ich den Topf der 480 Quellen von vorhin. Selbstverständlich müssen die Quellen des Caches eine begrenzte Gültigkeitsdauer haben.
|
__________________ |
| |
21. October 2005, 19:13
|
#3 | MODder
Registriert seit: 06.11.2003
Beiträge: 598
| Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Details Genau so habe ich das auch verstanden. Alles was über ist wird in nen großen Topf geworfen und nicht nochmal neu abgefragt,sondern bei Bedarf dort entnommen. Nur wenn der Topf leer ist werden neue Quellen gesucht und ein evtl. Überschuß abermals im Topf zwischengespeichert. Du hast doch damit mehr Erfahrung was wäre denn eine sinnvolle Zeit für eine solche Gültigkeitsdauer ?
Wenn die Quellen länger im Cache sind wie die normale Reask Zeit ist,würde ich sie erneut reasken...ansonsten einfach übernehmen.
MfG Max
__________________
Geändert von MaxUpload (21. October 2005 um 19:16 Uhr)
|
| |
21. October 2005, 20:04
|
#4 | Board Profi
Registriert seit: 22.05.2005
Beiträge: 1.116
| Lösung: Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Zitat:
Zitat von MaxUpload Wenn die Quellen länger im Cache sind wie die normale Reask Zeit ist,würde ich sie erneut reasken...ansonsten einfach übernehmen. | Eben nicht! Die Quellen des Cache sollen überhaupt nicht abgefragt werden. Meiner Meinung nach bräuchten sie auch gar nicht verworfen werden, denn wenn sie zum Zuge kommen, dann werden sie wie ganz normale Quellen, wie über XS erhaltene, behandelt. Ungültige Quellen fallen dann automatisch weg.
Hier mal mein Denkansatz:
Ich könnte mir einen Algorytmus vorstellen, der an die "zu vielen Verbindungen" geknüpft ist. Zunächst werden bei Start lediglich die ersten Quellen aller downloads, die man über server und/oder Kad bekommt, kontaktiert. Die über die ersten Quellen erhaltenen Quellen kommen zunächst alle in den cache.
Im nächsten Schritt werden allen downloads eine bestimmte Zahl (z.B. 5 Stück) von Quellen - vorausgesetzt es sind welche da - aus dem cache zugeordnet und abgefragt. Gehen die "zu vielen Verbindungen" auf Null, werden wieder eine festgelegte Zahl (z.B. 5 Stück) von Quellen allen dls zugeordnet und abgefragt ... usw. ... sollten die "zu vielen Verbindungen" in einem festen Zeitintervall (z.B. 10 Minuten) nicht mehr auf Null zurückgehen, dann werden die Quellen der dls, abhängig von der dl prio, wieder zurück in den cache geschickt - bei gleicher prio bei dem dl mit den meisten Quellen. Die in den cache zurückgeschickten Quellen kommen bei Bedarf als erste wieder an die Reihe.
edit/ für den reask after ip change müßte man sich eine Sonderregelung einfallen lassen, evtl. das Zeitfenster bis die "zu vielen Verbindungen" wieder auf Null gehen sollen, erhöhen.
__________________ Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein
Geändert von seppl12 (21. October 2005 um 20:08 Uhr)
|
| |
21. October 2005, 21:25
|
#5 | Senior Member
Registriert seit: 10.10.2005
Beiträge: 325
| Sinn und Unsinn von AutoHL's bzw. HL's allgemein. [gelöst] Man könnte allerdings auch empfangene quellen in die Known.met + Zusatzinfo "cached" versetzen. Evtl. temporär bannen (schließt traffik total aus und trotzdem kennen wir die quellen noch - sie werden uns wohl niemals sehen da wir sie nicht in die queue aufnehmen und nur ein hello - kein info packet senden). ahhh tut mir ned weh |
| |
21. October 2005, 21:31
|
#6 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Um der Nachvollziehbarkeit willen und um meine Meinung zum Thema nicht erneut zu schreiben der Auslöser: http://www.emule-web.de/board/showth...7054#post97054
und zum Quellencache: http://www.emule-web.de/board/showth...7066#post97066
Zum Cache muß man bitte bedenken, daß normalerweise alle 29 Minuten die Server in der Serverliste nach neuen Quellen gefragt werden, der Reihe nach. Es werden also mehr oder weniger kontinuierlich Quellenmeldungen eintreffen. Quellen, die ich eben noch gar nicht nutzen wollte, jetzt dank Cache ein paar Minuten früher abzufragen halte ich für Unfug. Hinzu kommt, daß über Kad und Quellenaustausch ebenfalls ein kontinuierlicher Strom an Quellenmeldungen eintrifft. Man könnte vielleicht die Besonderheit des Xtreme, gedroppte Quellen eine Weile nicht als neu gemeldete Quellen zu akzeptieren, modifizieren. Indem man die gedroppten Quellen im "Gedächtnis", also in einem Cache, behält. Genausogut kann man aber das Droppen seinlassen... Es ändert einfach nichts daran, daß ein Hardlimit überhaupt nur Sinn macht, wenn das Muli bereits falsch genutzt wird. Für alle von mir nicht genutzten Quellen bin ich eine potenzielle Quelle. Ich kastriere also meine Anfragen bei anderen um meinen Downloadoverhead zu senken, verursache aber bei anderen eine sinnlose Steigerung des ihrigen. Sinnlos deshalb, weil ich, wenn ich sogar meine Anfragen bei anderen kastriere schon lange den Punkt überschritten haben muß, bis zu dem es für andere sinnvoll ist, sich in meiner Warteschlange anzustellen.
Solch ein Cache macht nur wirklich Sinn, wenn ich mir keine Quellen mehr von Servern, Kad und Quellenaustausch melden lasse. Eine Quellenhalde von unvermeidlich schlechter Qualität, wo soll da ein Sinn sein? Was immer an Informationen ich dort horte ist älter, unaktueller und damit wertloser als das, was ich kontinuierlich gemeldet bekomme. Und da das Feature ja der Beschleunigung des Downloads dienen soll kann ich auf die Quellenmeldungen nicht verzichten. Wozu also?
Es gibt einen Fall, in dem ein solcher Cache sinnvoll ist, beim Neustart des Mulis. Diese Art Cache verbirgt sich hinter der Funktion Save/Load Sources.
@ seppl12:
Deine Überlegungen gehen in Richtung Verbindungsmanagement zum Routerschutz. Das hat nichts mit Hardlimits zu tun.
Mit freundlichen Grüßen
aalerich
P.S.: @ reLoaded:
Auch das gibt es bereits; es nennt sich z.B. "No Upload to NNS", das gleiche wäre erreichbar über "Ban on Drop"... Du kommst nicht darum herum, Du bist Quelle für die, die Du nicht als Quellen haben willst.
__________________ _______________________________________________ Der Router ist schuld! |
| |
21. October 2005, 22:10
|
#7 | Board Profi
Registriert seit: 22.05.2005
Beiträge: 1.116
| Zitat:
Zitat von reLoaded Man könnte allerdings auch empfangene quellen in die Known.met + Zusatzinfo "cached" versetzen | Halt ich jetzt nicht für so sinnvoll, da man damit die Kompatibilität zu anderen clients gefährdet. Zitat:
Zitat von reLoaded Evtl. temporär bannen (schließt traffik total aus und trotzdem kennen wir die quellen noch - sie werden uns wohl niemals sehen da wir sie nicht in die queue aufnehmen und nur ein hello - kein info packet senden). | Seh den Sinn noch nicht so recht. Zu den Quellen im cache braucht man ja nur, wie Xman schreibt, die Verbindungsdaten speichern. Warum trotzdem ein 'hello' schicken? Zitat:
Zitat von aalerich Es werden also mehr oder weniger kontinuierlich Quellenmeldungen eintreffen. Quellen, die ich eben noch gar nicht nutzen wollte, jetzt dank Cache ein paar Minuten früher abzufragen halte ich für Unfug. | Vielleicht versteh ich dich ja falsch, aber die Quellen sollen gar nicht abgefragt werden, sondern landen im cache und werden nur bei Bedarf den dls zugeordnet und abgefragt. Zitat:
Zitat von aalerich Für alle von mir nicht genutzten Quellen bin ich eine potenzielle Quelle | Nur dann, wenn du zur Quelle Kontakt aufnimmst kannst von dieser als 'Passive' aufgenommen werden. Über Server oder XS kannst ja immer zu Quelle werden. Zitat:
Zitat von aalerich Ich kastriere also meine Anfragen bei anderen um meinen Downloadoverhead zu senken, verursache aber bei anderen eine sinnlose Steigerung des ihrigen. | Sorry, versteh ich nicht. Wieso soll die Belastung (Overhead) der Quellen, die ich im cache aufbewahr, steigen? Zitat:
Zitat von aalerich Solch ein Cache macht nur wirklich Sinn, wenn ich mir keine Quellen mehr von Servern, Kad und Quellenaustausch melden lasse. | Richtig! Für dls, die noch Quellen im cache haben, braucht es das nicht -> Senkung des Overheads und der Netzlast. Zitat:
Zitat von aalerich Was immer an Informationen ich dort horte ist älter, unaktueller und damit wertloser als das, was ich kontinuierlich gemeldet bekomme. | Sehe ich nicht so! Die Verbindungsdaten zu den Quellen im cache ändern sich ja nicht minütlich. Und warum willst ständig deine Quellen gegen andere austauschen ... das hört sich ja fast schon wie der frühere edonkeyBot an. Zitat:
Zitat von aalerich Und da das Feature ja der Beschleunigung des Downloads dienen soll ... | Wurde mit keiner Silbe hier behauptet. Zitat:
Zitat von aalerich @ seppl12:
Deine Überlegungen gehen in Richtung Verbindungsmanagement zum Routerschutz. Das hat nichts mit Hardlimits zu tun. | Nein, sehe ich nicht so. Hat jetzt mit einem Router überhaupt nichts zu tun. Sondern ich stell mit die Frage, was die Gesamtquellenzahl am ehesten limitiert.
__________________ Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein |
| |
21. October 2005, 22:26
|
#8 | MODder
Registriert seit: 06.11.2003
Beiträge: 598
| Boah...na schön das ihr so angeregt diskutiert. Freut mich wirklich. Bevor ich mir das alles durchlese und auswerte wollte ich nur nochmal anmerken...@seppl12.
Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger.
Reasken wollte ich die Quellen erst wenn ich sie aus dem Cache entnehme ->da brauchbar und sie sich dort schon länger als wegen mir um mal ne Zahl zu nennen 45 Minuten befinden->einfach nur um einen aktuellen Status zu bekommen.
Der eigentliche Ansatzpunkt um wirklich was einzusparen ist der,daß erst nach neuen Quellen gesucht wird wenn der Cache leer ist. Egal ob man vorher bessere-> low QR finden würde oder nicht.
Für aalerich's Ausführungen bin ich heute leider nicht mehr aufnahmefähig genug. Ich werde sie aber mit Sicherheit wohlwollend studieren sobald es mein Geisteszustand wieder zuläßt.
MfG Max
Geändert von MaxUpload (21. October 2005 um 22:30 Uhr)
|
| |
21. October 2005, 22:47
|
#9 | Deaktiviert
Registriert seit: 26.03.2004
Beiträge: 1.499
| ähm sorry aber das was ihr hier schreibt ist nix anderes als wenn ich auf verbinden/trennen gehe und die quellen neu abfrage nach ne bestimmten zeit. Zitat:
maxupload
Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger. | meiner ansicht nach verbinden / trennen.... sorry aber das produziert overhead ohne ende !!!!!!!
finde ich net toll !!!!
somit kann noch mehr legal geleecht werden... muss net sein find ich ! |
| |
21. October 2005, 22:58
|
#10 | Board Profi
Registriert seit: 22.05.2005
Beiträge: 1.116
| Zitat:
Zitat von MaxUpload Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger. | Genau das hab ich oben geschrieben. Nur warum beschränkte Gültigkeitsdauer? Ein Quelle kann über Wochen gültig bleiben, oder sagen wir mal 12 Stunden als Mittelwert der Quellen mit 24h Zwangstrennung (Gleichverteilung vorausgesetzt). Zitat:
Zitat von MaxUpload Reasken wollte ich die Quellen erst wenn ich sie aus dem Cache entnehme ->da brauchbar und sie sich dort schon länger als wegen mir um mal ne Zahl zu nennen 45 Minuten befinden->einfach nur um einen aktuellen Status zu bekommen. | Ich würde die Quellen aus dem cache erst dann rausnehmen und nachfragen, wenn ich sie auch einem dl fest zuordne. Also nicht so zwischendurch mal kurz "antesten" wenn man sie eh nicht nutzen will. Kriterien könnten sein:
- dls mit weniger Quellen als der Durchschnitt aller dls
- gewisser Prozentsatz der Quellen eines dls sind NNP und full Zitat:
Zitat von MaxUpload Der eigentliche Ansatzpunkt um wirklich was einzusparen ist der,daß erst nach neuen Quellen gesucht wird wenn der Cache leer ist. Egal ob man vorher bessere-> low QR finden würde oder nicht. | Sehe ich auch so. Nur würde ich gedroppte Quellen wieder in den cache stecken. Aber ich seh schon, mein Vorschlag hat nichts mit AutoHL zu tun, sondern geht eher in Richtung "intelligentes" Quellenmanagement.
__________________ Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein |
| |
22. October 2005, 01:03
|
#11 | MODder
Registriert seit: 06.11.2003
Beiträge: 598
| @drfreak2004 : Darüber denke ich nochmal nach wenn ich klar bei Sinnen bin. Glaub irgendwas paßt hier nicht. Wir reden aneinander vorbei.
@seppl12 Zitat:
Ich würde die Quellen aus dem cache erst dann rausnehmen und nachfragen, wenn ich sie auch einem dl fest zuordne. Also nicht so zwischendurch mal kurz "antesten" wenn man sie eh nicht nutzen will.
| Ja genau davon spreche ich doch die ganze Zeit. Es sollen nicht mehr Quellen gesucht ,sondern überschüssige nicht gedroppt und stattdessen in einen Zwischenspeicher gepackt werden. Da diese nicht Reask werden solange sie sich in diesem Zwischen-Speicher befinden brauchen sie eine Gültigkeitsdauer. Die sollte groß genug sein um nicht zu viele brauchbare Quellen zu verlieren,aber auch niedrig genug um nicht nur noch Schrott im Cache zu haben.
Wenn nun bei einem File der Bedarf nach mehr Quellen da ist.
Werden diese bevorzugt aus dem Cache genommen.
Sollte die Quelle aus dem Cache schon etwas älter sein würde ich sie neu anfragen,aber erst in dem Augenblick wenn ich sie dem DL wie du sagtest fest zuordne und erst nach einer relativ langen Zeit um sicher zu sein,das der Client noch online ist. Ob nun nach 30 Minuten oder 2 Tagen mag ne Frage des Erprobens sein.
Keinesfalls soll der Cache künstlich gefüllt werden,sondern nur der Überschuß der sonst gedroppt oder was auch immer würde dort gelagert werden.
Auch soll es keine neuen Anfragen ins Netz geben solange im Cache noch gültige (Gültigkeitsdauer nicht überschritten,Client noch verfügbar....keinesfalls QR-Rankings oder ähnliches) Quellen verfügbar sind.
Erst wenn es im Cache keine brauchbaren Quellen mehr gibt und noch Bedarf da ist werden neue Quellen gesucht. Sollten dabei mehr Quellen als benötigt gefunden werden landen diese wieder im Cache.....usw. ...usw. ...usw. .
Mit völlig übermüdeten Grüßen
Max |
| |
22. October 2005, 03:26
|
#12 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Ich frage doch alle 29 Minuten die Server nach neuen Quellen. Alle 29 Minuten bekomme ich also von allen Servern in meiner Liste den aktuellsten Stand. Was ich vor z.B. zwei Stunden in meinen Cache geschrieben habe ist dann doch völlig bedeutungslos, es ist veraltet. Selbst bei unverändert verfügbaren Quellen bringt der Cache keinen Vorteil. Die maximal durch den Cache zu überbrückende Zeit beträgt 29 Minuten und auch das nur, wenn Kad und Quellenaustausch abgeschaltet sind. Mit Kad und Quellenaustausch bekomme ich permanent aktuelle Daten gemeldet. Brauche ich eine neue Quelle kann ich sie aus diesen Meldungen nehmen. Es geht hier um einzelne Quellen, ein paar Minuten Verzögerung sind bedeutungslos. Jedenfalls, solange man nicht auf Teufel komm raus saugen will. Und es besteht die Gefahr, veraltete Quellenangaben zu nutzen und also ins Leere hinein abzufragen. Da es sich um einzelne Quellen handelt auch nicht wirklich gefährlich, aber doch ein Nachteil ohne wirklichen Vorteil. Sinnvoll wäre höchstens (wie im Xtreme ja gelöst), daß ich die vom Server gemeldeten, von mir aber nicht genutzten Quellen auf eine Liste der nicht abzufragenden Quellen setze. Das ist aber kein Cache. Man könnte diese Liste jetzt natürlich nehmen und bei Ausfall einer akzeptierten Quelle (z.B. derjenige geht offline) eine aus der Liste quasi wieder freigeben und abfragen. Nur: Lohnt das? Gemeldet bekomme ich diese Quelle und nach einer Stunde wird sie von Xtreme ohnehin wieder freigegeben. Im allerschlimmsten Falle nutze ich diese Quelle also rund eine Stunde später als möglich. Da das Droppen aber wohl in jedem Falle mehrere hundert nicht gedroppte Quellen voraussetzt macht diese eine Stunde Verzögerung für eine Quelle den Kohl doch nun wirklich nicht fett. Wenn Ihr das programmieren wollt, bitte, nur wird es keinerlei Auswirkungen haben. Es wäre wesentlich vernünftiger, gar nicht zu droppen.
Wenn ich 10 000 potenzielle Quellen habe bin ich in die andere Richtung potenzielle Quelle für diese 10 000 Klienten. Nutze ich 5 000 davon nicht frage ich sie nicht ab und reduziere dadurch meinen Overhead ebenso wie den der nicht Abgefragten, die ja nicht antworten müssen. So weit, so gut. Nur fliegen meine Daten ja über Server, Kad und Quellenaustausch im Netzwerk umher. Die von mir nicht genutzten 5 000 Quellen bekommen mich also als Quelle für sich selbst gemeldet und fragen mich ab. Und ich antworte. Ich nutze daher nur 5 000 Quellen, verursache aber Overhead für diese 5 000 plus halben Overhead (halt nur aus meiner Sicht Uploadrichtung) für die nicht genutzten 5 000 Quellen. Genutzt werden also 5 000 Quellen bei einem Overhead für 7 500 Quellen.
Ich halte den Cache für eine nutzlose Funktion mit minimalem zusätzlichen Overhead. Jedes Hardlimit aber bedeutet eine drastische Erhöhung des Overheads im Netzwerk. Die Hälfte aller möglichen Quellen nicht zu nutzen bedeutet 50% mehr Overhead für Fragen/Antworten. Z.B., wenn ich bei Standard-DSL Dateien mit insgesamt 8 000 Quellen bestelle und mittels Hardlimit nur 4 000 nutze erzeuge ich Overhead, als würden meine Bestellungen ohne Hardlimit 6 000 Gesamtquellen haben. Da kann ich doch gleich bei 6 000 Quellen anstehen, es kommt overheadmäßig aufs selbe raus. Nur daß ich in letzterem Falle eben auch die 6 000 Quellen nutze. Ich nutze also 2 000 Quellen mehr und dementsprechend besser wird mein Download sein. Sind 6 000 Quellen aber zuviel überfordere ich mein Muli dank Hardlimit, obwohl ich ja nur 4 000 Quellen nutze...
@ drfreak:
Nee, ich speichere eine Quelle als IP/Portkombination. Nach 24 Stunden hat aber praktisch jeder seine ZT gehabt und daher sind praktisch all diese Daten wertlos geworden. 24 Stunden wäre also die extremste Verfallszeit, alles darüber kann nichts mehr bringen. Verfallszeit meint also eine realistische Zeitspanne, in der angenommen werden kann, daß die gespeicherte Quelle noch unter der IP/Portkombination erreichbar ist.
Mit freundlichen Grüßen
aalerich
__________________ _______________________________________________ Der Router ist schuld! |
| |
22. October 2005, 08:38
|
#13 | Deaktiviert
Registriert seit: 26.03.2004
Beiträge: 1.499
| stimmt zwar rein progi technisch... aber weist du wieviel alte emule user die von anfang an dabei sind die angewohnheit haben, ihren verbindung neu zu machen ? dies bedeutet, das du nicht sicher weist, ob der emule client den du haben willst noch da ist oder net ?! also ich find des sehr fragwürdig des ganze....
mfg
edit : was sagt ornis+ und co dazu ?! |
| |
22. October 2005, 10:06
|
#14 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Ja eben, deshalb muß, ähnlich wie bei SLS, eine vernünftige Verfallszeit gefunden werden. 2 Stunden z.B. wären vermutlich durchaus sinnvoll; rein rechnerisch würde in dieser Zeit ein Zwölftel der Informationen falsch werden. Mein Punkt ist nun aber der, daß ich ja alle halbe Stunde aktuelle Daten vom Server bekomme plus die vom Quellenaustausch und Kad, die ja als relativ gleichmäßiger Strom kommen. Darum macht so ein Cache nicht wirklich Sinn. Wenn mir eine Quelle ausfällt kann ich auch ein paar Minuten warten bis ich eine aktuelle gemeldet bekomme und die dann nehmen.
Mit freundlichen Grüßen
aalerich
__________________ _______________________________________________ Der Router ist schuld! |
| |
22. October 2005, 10:29
|
#15 | MODder
Registriert seit: 28.03.2003
Beiträge: 5.800
| @aalerich
stimmt nicht was Du sagst... 29 Minuten beziehen sich alleine auf die Quellen-Reask-Zeit.. haben aber nichts mit Quellen finden zu tun.
Die Quellenneufindung über Server läuft glaub ich alle 10 Minuten (bin da nicht sicher)... über XS sehr variabel und nicht so einfach zu erklären... über Kad->Null Ahnung, aber nicht so häufig. Per server bekommst Du auch immer sehr wenige Quellen... die große Anzahl kommt über XS.
Ein source-chache ist nach meinem Codeverständnis also sehr sinnvoll. Gültigkeitsdauer könnte so zwischen 15 Minuten und einer Stunde liegen... würde mal mit 30 Minuten anfangen... und dann den Code optimieren und das ganze durchberechnen/testen.
__________________ |
| |
Forumregeln
| Es ist Ihnen nicht erlaubt, neue Themen zu verfassen. Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten. Es ist Ihnen nicht erlaubt, Anhänge hochzuladen. Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten. HTML-Code ist aus. | | | Alle Zeitangaben in WEZ +1. Es ist jetzt 13:14 Uhr.
|