Gruppe Webis2 Vorstellung des Projektes „ M agic M edia S earch“

1. Gruppe Webis2Vorstellung des Projektes „MagicMediaSearch“ www.mms.de.vu Sven Bittner, Moritz Blöcker, Valerie Bures, Heiko Kahmann, Mariusz Kukulski, Kilian Lenz, Olaf Licht, Fabian Wiesel, Thomas Zahn 24.01.2001

2. Gliederung • Einleitung und Aufgabenstellung • Gruppenübersicht und Verteilung der Aufgaben • Vorstellung der Teilaufgaben: • Crawler (Heiko) • Web-Parser (Mariusz) • Indexer und Index (Thomas) • Searcher (Fabian) • Ranker (Moritz) • GUI und GUI-Parser (Sven) • Testszenarien • Probleme und Verbesserungsmöglichkeiten • Onlinepräsentation des kompletten Systems

3. Einleitung und Aufgabenstellung • Es soll eine Suchmaschine für Medien-Dateien (insbesondere mp3-Files etc.) in JAVA programmiert werden, die über ein Web-Interface abgefragt werden kann. • Die in der VL vorgestellten Verfahren und Algorithmen sollen angewendet werden. • Das System soll aus Crawler, Parser, Index, Retrieval-Einheit bestehen. • Zu indexieren ist/sind: • HTML oder ASCII-Text (sog. „Textseiten“) • Dateien mit Musik bzw. Video (sog. „Mediendateien“) • Lexikographische Vorverarbeitung: • Stemming (deutsch und englisch) • Stoppwortentfernung (deutsch und englisch) • Einbindung eines Thesaurus (wenn möglich) • Anfragesprache: • Anfragen auf Titel (matching) und Wortanfänge mit geranktem Ergebnis • Phrasensuche • Proximity-Operatoren (nearby ...)

4. List von URLs Internet Crawler Web Parser Index Indexer GUI Parser Search GUI Ranker Verteilung der Aufgaben • Mariusz, Heiko und Sven:Crawler, WebParser und URL-Liste • Kilian, Thomas und Valerie:Index und den Indexer • Fabian und Olaf:Searcher • Moritz:Ranker • Sven:GUI und den GUI-Parser Dieses Diagramm gibt einen groben Anhaltspunkt und nicht die eigentliche Klassenaufteilung wieder!

5. CrawlerGliederung • 1.Was ist der Crawler ? • 2. Wie ist der HTMLCrawler standardmässig aufgebaut ? • 3. Welche weiteren Features besitzt unser HTMLCrawler • 3.1 Serielles Laden • 3.2 Paralleles Laden • 3.3 Arbeiten mit einer „URLList“ • 3.4 Beachtung von „Robot.txt“ • 3.5 Laden von MP3-Attributen • 4. Sinnvolle Erweiterungen • 4.1 Setzen eines TimeOuts für die URLConnection • 4.2 Einsatz einer CrawlerQueue

6. CrawlerFunktion und Aufbau • 1. Was ist der Crawler ? • Crawler bedeutet „Kriecher“, „Kriechtier“ oder auch „Laufkette“ • Der Crawler „kriecht“ durch das Internet und sammelt Informationen • Crawler.java ist unser Interface für den HTMLCrawler.java • 2. Wie ist der Crawler standardmässig aufgebaut ? • Er besitzt die Funktion „Accumulator loadWebSite(URL url)“ • Auf dem URL-Object nutzt er die Funktion openConnection() • -> erhalten eines URLConnection-Objects • -> Auslesen benötigter Informationen über einen InputStream • der URLConnection (Siehe Vortrag über Internetverbindung über Java) • Rückgabewert ist ein Object vom Typ Accumulator mit Inhalt • „WebSite als String“, „LastModified als Date“, und die URL der Seite

7. CrawlerFeatures des HTML-Crawlers • 3.1 Serielles Laden • - ein aussenstehender Prozess (SeriellWebParser) übergibt dem • HTMLCrawler eine zu ladende URL und wartet, bis die Funktion • loadWebSite() das Ergebnis zurückliefert. • - Nachteil : • -> der aussenstehende Prozess (z.B. SeriellWebParser) • wartet die Zeit des Ladevorganges auf das Weiterarbeiten • - Vorteil : • -> einfacher Einsatz, einfache Kommunikation Beliebiger Prozess z.B. SeriellWebParser HTMLCrawler Ladevorgang

8. CrawlerFeatures des HTML-Crawlers Beliebiger Prozess z.B. ParallelWebParser HTMLCrawler Weitere Arbeit des Prozesses Ladevorgang • 3.2 Paralleles Laden • - ein aussenstehender Prozess (SeriellWebParser) übergibt dem • HTMLCrawler eine zu ladende URL. Der aussenstehende • Prozess kann weiter arbeiten, in der Zeit, in der der • HTMLCrawler die Informationen lädt. • - Nachteil : • -> komplizierte Kommunikation • (siehe später Stichwort CrawlerQueue) • - Vorteil : • -> kein Zeitverlust für aussenstehenden Prozess, z.B • ParallelWebParser

9. CrawlerFeatures des HTML-Crawlers URL checkURL(URL url) Prozess, z.B. SeriellWebParser HTMLCrawler URLList Accumulator URLFoundException • 3.3 Arbeiten mit einer URLList • - Die URLList ist nicht die Liste der zu besuchenden URL´s • - Die URLList ist ein Object zum Testen, ob eine URL schon geladen wurde. (Beim Testen wird die URL abgespeichert) • - Nachteil : • -> Zeitverlust durch Vergleich aktueller URL mit allen schon • geladenen URL´s • - Vorteil : • -> Verhindern von Schleifen, die durch gegenseitige • Referenzierung von HTML-Seiten entstehen

10. CrawlerFeatures des HTML-Crawlers URL Vergleich Prozess, z.B. SeriellWebParser HTMLCrawler Robot.txt Accumulator True / False • 3.4 Beachtung von Robot.txt - Dateien • - Robot.txt - Dateien liegen auf den HTTP-Servern • - Robot.txt - enthält alle URL´s, die nicht vom Server • geladen werden können • - Pro zu ladender URL wird die Robot.txt - Datei angefordert • und mit der aktuellen URL verglichen • - Nachteil : • -> Zeitverlust durch Vergleich aktueller URL mit den Robot.txt - URL´s • - Vorteil : • -> Verhindern eines Hängenbleibens des Systems, verursacht durch eine „hängende“ URLConnection

11. CrawlerFeatures des HTML-Crawlers • 3.5 Auslesen von MP3 - Attributen • - MP3´s enthalten neben dem Lied auch Meta-Infomationen, • wie z.B. Autor, Komponist, Band, Album, LastModified, ... • - Crawler besitzt dazu die seriell arbeitende Funktion • Accumulator loadMP3File(URL url) • -> Accumulator enthält alle Informationen, die das MP3-File • auszeichnen • - Nachteil : • -> Zeitverlust durch öffnen einer neuen Verbindung • zum MP3-File • - Vorteil : • -> Starke qualitative Steigerung der SearchEngine, da das • MP3-File die genauesten Informationen über sich selbst • besitzt (besser als Linktext, Umgebungstext, Link selbst)

12. CrawlerSinnvolle Erweiterungen URL Start Prozess, z.B. SeriellWebParser HTMLCrawler TimeOut ist eigener Thread Accumulator / CrawlerException disconnect() • 4.1 Setzen eines TimeOuts für die URLConnection • - TimeOut ist ein parallel laufender Prozess (eigener Thread) • - einem Crawler (HTMLCrawler) kann ein TimeOutObject • gesetzt werden. • - Dem TimeOutObject wird eine Zeit mitgegeben, nach der • es die URLConnection eines Crawlers schliesst. • - Nachteil : • -> TimeOut musste selbst entwickelt werden, da die URLConnection dies nicht als Standard unterstützt • - Vorteil : • -> Schnelligkeitssteigerung des Indexierungssystems, durch vorzeitiges Trennen „langer Leitungen“

13. CrawlerSinnvolle Erweiterungen CrawlerQueue Parallel ladender HTMLCrawler setURL(URL) Prozess, z.B. ParallelWebParser Parallel ladender HTMLCrawler getNextCrawlerContent() isReady() Parallel ladender HTMLCrawler Accumulator • 4.2 Nutzen einer Crawler-Queue • - Crawler-Queue ist eine Prioritäts-Schlange von n parallel arbeitenden HTML-Crawlern • - Crawler-Queue kapselt die Kommunikationsaufwand, den • parallel arbeitende HTML-Crawler verursachen • - Arbeitsweise : • - Nachteil : • -> Synchronisation aller parallel arbeitenden HTMLCrawler • ist sehr kompliziert (JavaThreads arbeiten nicht wirklich parallel) • - Vorteil : • -> Im Prinzip keine Wartezeiten für den ParallelWebParser in Bezug auf den HTMLCrawler • -> sehr hoher Datendurchsatz erreichbar.

14. Web-Parser • Was wird vom Web-Parser verlangt? • Wie arbeitet der Web-Parser? • Besonderheiten des Web-Parsers • Probleme und mögliche Ergänzungen

15. Web-Parser • Was wird vom Web-Parser verlangt (1/3)? • Der Web-Parser soll aus den vom Crawler geladenen Seiten schnell die wichtigsten Informationen filtern. • Was sind für unsere Suchmaschine wichtige Informationen? • Verweise auf andere Internet-Seiten. • Internet-Seiten die Mediendateien enthalten. • Mediendateien mit Link-Text, Link-Umgebung und URL (bei .mp3-Dateien auch der Inhalt der mp3-Tags)

16. Web-Parser • Was wird noch vom Web-Parser verlangt (2/3)? • Der Web-Parser soll den Indexaufbau managen (d.h. Crawler, URLList, URLVector und den Indexer mit Index verwalten). • Warum soll diese Aufgabe der Web-Parser übernehmen? • Das Design ist mehr aus der Not entstanden. • Der Web-Parser ist das Bindeglied zwischen Crawler und Indexer und und ruft beide bei Bedarf auf.

17. Web-Parser • Was wird noch vom Web-Parser verlangt (3/3)? • Der Web-Parser soll entscheiden in welchen Index eingetragen wird und sendet „entsprechende Pakete“ an den Indexer. • Was heißt hier „entsprechende Pakete“? • Für Einträge im • - Medienindex :(Word, MediaURL, Datum, MediaType, SeitenURL, Sprache, Gewichtung, Position, Überschrift). • - Textindex :Word(LowerCase), URL, Datum, Type, "", Sprache, 0, 0, Überschrift).

18. Web-Parser • Wie arbeitet der Web-Parser? MP3-Crawler Bei .mp3-Dateien zum Auslesen des MP3-Tags Web-Parser Einlesen der Internet-Seiten (.htm, .html, .shtml u.s.w.) Eintragen der relevanten Informationen Crawler Indexer

19. Web-Parser • Wie arbeitet der Web-Parser? Web-Parser removeStopwords() Müll URLVector Spracherkennung Hat der tagIdentifier() Mediendateien erkannt, werden diese markiert und der Indexierungsvorgang wird begonnen. Falls nicht wird die nächste URL aus dem URLVector über den Crawler angefragt. Entscheidung durch URLListe bei Bedarf MP3-Crawler tagIdentifier() mediaIndexParser() linkParser() indexieren im Medienindex Seite ohne Scripte und Stylesheets removeStopwords() htmlIndexParser() ScriptAndStylesheetDeleter() Stemmer indexieren im Textindex neue Internet-Seite

20. Web-Parser • Besonderheiten des Web-Parsers • Möglichkeiten der Modifizierung in der .properties-Datei: • mediaIndexLinkArea(int) gibt die Umgebung des Links an, der in den Medienindex eingetragen wird. • maxvectorsize(int) gibt die maximale URLVectorgröße an. • saveDataAfterNParsedSites(int) gibt an, nach wie vielen geparsten Seiten der Index, der URLVector und die URLList gespeichert werden sollen. • textFileTypes(String) enthält die Endungen der lesbaren Internet- Dateien, die vom Crawler geladen werden sollen (aktuell : „html shtml htm“ ). • mediaFileTypes(String) enthält die Endungen aller Mediendateien, die indexiert werden sollen (aktuell : „mp3 mpeg avi wav ram mpg mov“ ).

21. Web-Parser • Probleme und mögliche Ergänzungen • Leider zu wenig Zeit für die Planung des Web-Parsers, durch sehr späten Wegfall der zuständigen Gruppe. • Der sprach-spezifische Stemmer benötigt für eine Seite, die in den Textindex eingetragen wird sehr viel Zeit (ca. 4/5 des gesamten Parsingprozesses). • Die Entfernung des Stemmers würde das Parsen stark beschleunigen, den Index jedoch wesentlich vergrößern (und somit auch die Wartezeit, von der Seite der GUI aus, erhöhen). • Anfangs wird Breitensuche betrieben. Wenn allerdings der URLVector seine Maximalgröße erlangt, werden viele, möglicherweise wertvolle, URL´s ignoriert. Die Breitensuche wird zur Tiefensuche.

22. Indexer und IndexGliederung • Anforderungen an den Index • Implementation • Datenstruktur des Index • UML • Indexierungsvorgang • Aktuelle Indexdaten und -größe • Testmöglichkeiten • Indexierungszeiten • Probleme und mögliche Ergänzungen

23. Indexer und IndexAnforderungen an den Index • Der Index ist das "Gedächtnis" der Suchmaschine. Hier müssen die Daten der geparsten Dokumente effizient gespeichert werden, um schnelles Suchen zu gewährleisten. • Der Index soll sowohl Wörter aus HTML-Dokumenten als auch Wörter bzgl. Mediendateien (z.B. Filename, MP3-tag etc.) enthalten. Ferner soll eine Unterscheidung nach Medienart, Sprache, Alter etc. möglich sein. • Medienterme sollen nicht gestemmt werden (Phrasensuche!) • Textterme werden gestemmt • Die Indexstruktur muß folgende Suchanfragen unterstützen: • nach einzelnen Wörtern • Wortanfänge • Phrasen (nur im Medienindex) • Near-By • Optimierung der Suchgeschwindigkeit • Die Indexierungszeit ist weniger relevant • Optimierung des Speicherverbrauches durch Kompression

24. Indexer und IndexImplementation • Es gibt zwei identische Index-Strukturen. Eine für die Medien-Terme und eine für die Text-Terme, (damit im Medien-Index die Phrasensuche möglich ist, müssen die Positionen der Wörter gespeichert werden). • Für die Zuordnung Term -> Dokument werden Inverslisten benutzt • Beim Text-Index wird zusätzlich die jeweilige Termfrequenz gespeichert. • Im Medien-Index stattdessen ein Rankingfaktor und die Position des Wortes im Dokument • Die Inverslisten sind gammacodiert. • Die dokumentspezifischen Daten werden in einer Liste verwaltet: • URL • Medientyp (0=html, 1=ascii, 2=mp3, 3=mpeg, 4=avi usw.) • Sprache (0=deutsch, 1=englisch...) • Kurzer Ausschnitt (Headline o. ä.) • Datum der letzten Änderung • bei Mediendateien auch die URL der Seite, die auf diese Datei zeigt • Als Grundgerüst für die beiden Indexe wird ein Prefix-Tree verwendet, der sowohl in den Knoten als auch in den Kanten je einen Verweis zu einer Inversliste enthalten kann. • Die Klasse „Index“ enthält sowohl beide Prefix-Trees als auch die Dokumentenliste als Objekte.

25. 0100111101111010... Postingliste mit drei gamma-codierten BitSets für die Doc-IDs, die Gewichte und die Termpositionen zu jedem Term 1001110100101010... Daten 1111001010101101... b s 0100111101111010011010011010... 0111010101101001110100101010... ank peicher 1101001101011111001010101101... a s m Verkettete Liste mit genaueren Informa- tionen zu den Dokumenten nwend- ung ystem edium URL A HTML ... URL B MP3 ... URL C HTML ... Indexer und Index Datenstruktur des Index 2 Prefix-Trees (1x Text-Index, 1x Medien-Index)

26. Indexer und Index UML

27. Indexer und Index Indexierungsvorgang • Der Web-Parser ruft den Indexer auf und übergibt die notwendigen Daten • Der Indexer entscheidet anhand des Medientyps und des Aufrufs in welchem Index der Term eingetragen werden soll (ein Term wird in beide Indexe eingetragen, wenn er sich in der Link-Umgebung einer Mediendatei befindet). • Aufruf der Index-Klasse zum Speichern der dokumentspezifischen Daten. • Aufruf der Index-Klasse zum Speichern der termbezogenen Daten • Text-Index: • Gibt es den Term schon? Dann erhöhe die Termfrequenz um 1, falls Dokument-ID schon bekannt, sonst ergänze die Inversliste mit neuer Dok-ID und Termfrequenz 1 • Unbekannter Term? Speichere Term im Baum und setze neue Inversliste mit Termfrequenz 1 • Medien-Index: • Gibt es den Term schon? Ergänze Inversliste um neue Dok-ID, Ranking-Faktor und Position • Sonst: Erzeuge vorher neuen Eintrag im Baum mit entsprechender Postingliste • Der Indexer kann auch einen schon vorhandenen Index (File) laden, ergänzen und wieder speichern.

28. Indexer und Index Aktuelle Indexdaten und -größe • Anzahl an Termen • im MedienIndex: 19096 • im TextIndex: 15727 • Größe der Dokumentenliste: 7100 • davon deutsche Dokumente 101 • englische Dokumente 6999 • Anzahl verschiedener Dokumenttypen: • HTML/ASCII 211 • MP3 6880 • MPEG 1 • AVI 1 • WAV 0 • RAM 0 • MPG 2 • MOV 5 • Speicherverbrauch: • File: 10.5 MB • RAM: ca. 37.5 MB

29. Indexer und Index Testmöglichkeiten • Mittels der Klasse „IndexStats“ kann der Inhalt des gesamten Indexes in lesbarer Form in 3 Textdateien ausgegeben werden: • Alle Terme des Text-Indexes werden mit der Länge der zugehörigen Inversliste ausgegeben • Alle Terme des Medien-Indexes werden mit der Inverslistenlänge ausgegeben • Die Dokumentenliste wird mit allen Einträgen ausgegeben • Die verschiedenen Medientypen werden ebenfalls gezählt. • Anhand dieser Daten konnten in der Testphase etliche Fehler beseitigt und Verbesserungen (Speicherverbrauch, Parser etc.) vorgenommen werden. • Die Suchzeiten liegen im Millisekundenbereich.

30. Indexer und Index Indexierungszeiten • Für den ersten Test des Indexers/Indexes wurde die Man-Page-Sammlung aus 528 Dateien genutzt und nur Wörter aufgenommen, die länger als 3 Buchstaben waren. • Die Indexierungszeit wurde jeweils für ein komplettes Dokument gemessen und dann durch die Anzahl der Terme dividiert. (Die Zeiten für eine einzige Term-Indexierung waren bis zu einer bestimmten Indexgröße nicht meßbar.) • Zeitwachstum mit O(n*log(n)). • Durch gesonderte Test konnte gezeigt werden, daß die Lauf-Zeit hauptsächlich von den Posting-Listen bestimmt ist. Da diese häufig codiert/decodiert werden müssen und des Gammacodes wegen nur sequentiellen Zugriff erlauben. • Zeit: ca. 1 h für man-page-Index

31. Indexer und Index Probleme und mögliche Ergänzungen • Das Löschen bzw. Aktualisieren der Daten im Hinblick auf das Entfernen von Dokumenteinträgen ist nicht vorgesehen. • Es wäre möglich aber recht aufwendig, da alle Postinglisten zu jedem Term durchsucht und dann die betreffenden Dokument-IDs gelöscht werden müßten.

32. GUI und GUI-Parser • Klasse GUIWorker: • zentrale Methode Vector doWork( SuchString, Suchart, Sprache ) • Parsen der Eingabe mit Durchführung des entsprechenden • Stemmings (je nach Sprache) • Suchen • Ranken • eine Instanz des Index als statisches Objekt und somit nur • einmaliges Laden der Indexdatei • GUI Eingaben/Einstellungen: • Suchstring • Suchart (HTML-Seiten oder Mediendateien) • Sprache (deutsch, englisch oder beide) • Anzahl der Suchergebnisse pro Seite

33. GUI und GUI-Parser • Aufgaben: • Wandelung der Texteingabe in ein für den Searcher nutzbares Format • Verarbeitung der getroffenen Einstellungen (Sprache etc) • Ausführen der Suche, bestimmen einer Rangfolge • Ausgabe der Ergebnisse • Realisierung: • Verwendung eines Servlets • Vereinfachung der Ausgaben durch Einbindung des • Open-Source-Frameworks Webmacro

34. GUI und GUI-Parser • Anfragesprache: • <EXPR> = <TERM> <AND> <EXPR> • <TERM> = {<WORD> | <PREFIX>} OR <TERM> • <AND> = AND | ANDNOT • <CHAR> = A | B | ... | Z | a | b | .. | z | 1 | 2 | ... • <WORD> = <CHAR>+ | ‘{<CHAR> | _}+' | (<EXPR>) • <PREFIX> = <CHAR>+<STAR> • <STAR> = * • Vertauschen der Bindungsstärke von UND/ODER • computer AND windows OR unix • = = • computer AND ( windows OR unix ) • Synonyme: • AND UND, & • ANDNOT BUT, UNDNICHT, AUSSER, &! • OR ODER, |

35. GUI und GUI-Parser • verwendete Klassen: • GUIServlet - das Servlet • GUIWorker - Verbinden aller benötigten Komponenten • GUIParser - Parser für Eingaben • Zusammenhang zwischen den einzelnen Komponenten:

36. Searcher • Anforderungen • Anbindung • Interna • Schwachpunkte/Alternativen

37. Searcher • Ziel: Geparste Anfragen sollen in eine bewertbare Dokumentenmenge umgesetzt werden • Anfrageoperationen • AND • OR • BUT • Präfix • Phrase (Medienindex) • Einschränkung auf bestimme Sprache

38. Searcher • Anbindung an Index: • Rückgabe einer sortierten Liste (Iterator, welcher Ordnung garantiert) • Präfixsuche im Index • Anbindung an Ranker: • Collection der DocumentIDs in den einzelnen Postinglisten • Information über ursprüngliche Größe der Postingliste und ihrer Terme • Anfrage realisiert als Ausdrucksbaum

39. Searcher • Zurückgegeben Postinglisten fehlt Information über Term und ursprüngliche Größe • Wie sollen die Informationen über die Rekursionsstufen zurückgereicht werden • Minimierung der Arbeit auf niedrigster Rekursionsstufe, da ursprüngliche Postinglisten sehr groß sein können

40. Searcher • Speichern zu jedem Term • Nachteil: Größerer Aufwand auf unterster Rekursionsebene • Einmaliges Speichern in Postingliste und Akkumulation der Postinglisten • Nachteil: Geringer sinkender Aufwand über Rekursionstufen, da über alle Elemente aller Postinglisten iteratiert wird, auch wenn mehrfach vorhanden sind

41. Searcher • Vorverarbeitung des Operatorbaums • Operatorbaum -> Gerichteter Ausdrucksgraph • Logische Vorverabeitung der Anfrage zur besseren Schnittbildung • Anbindung an Index • Direktes Arbeiten auf Index statt vorheriger Umwandlung

42. Ranker • Anforderungen • Anbindung • Interna • Schwachpunkte/Alternativen

43. RankerAnforderungen • schnelles Ranking • sinnvolles Ranking

44. RankerAnbindung • Die Anbindung erfolgt über die Klasse ListTransformer. • Bekommt eine DokumentListe • beinhalted: • DokumentFrequenzen • Termfrequenzen (bzgl. Der Indexmenge) • die Positionen + Gewichte der Positionen (bei MedienObjekten) • Rückgabe sind DocId‘s , erfolgt mit den Methoden: • rank() • getnBestElements()

45. RankerInterna • Der Ranker berechnet über alle Terme pro Dokument: • Dokumentfrequenz / Termfrequenz (bei Textanfragen) • Für die Summe der Vorkommen : Gewicht der Position / Termfrequenz (bei Mediaanfragen) • Kommentar: • zwar naiv gerangt, liefert aber vernünftige Ergebnisse

46. RankerSchwachpunkte / Alternativen • Alternativen : • siehe Vorlesung • Schwachpunkte : • Ranker liest immer gesamte Treffermenge => evtl. längere Verzögerung • Verbesserungsmöglichkeiten: • Speicherung im Heap der nur die besten n Documente speichert • Andere Datenstrukturen (bessere als die JDK Klassen) • andere Ranker testen ? • andere Gewichtung der TextPositionen ?

47. Testszenarien 1 • Durchfuehren aller Testszenarien unter www.mms.de.vu/testszenarios -> 32 Testszenarios • Probleme : • Es muß getestet werden, was über die GUI angeboten wird -> viele Testszenarien -> Zeitaufwand zum Testen zu groß • Möglichkeiten der Beschreibung der TestSzenarien sind zu gering • kaum Möglichkeit zum Projektvergleich mit anderem System, daher ist die Bewertung der Ergebnisse sehr schwer. • Folgerung : • wenig Testszenarien konnten durchgeführt werden • Viele Werte konnten fast „subjectiv“ bewertet werden. • Verbesserung : • Früherer Abgleich mit anderer Projektgruppe über Strukturen und Datenspeicherung • manuelle Datenausgabe ohne GUI • weniger „basteln an Kleinigkeiten“, dafür Tests besser planen und durchführen

48. Testszenarien 2 • Anzahl der eingelesenen Indexeintraege nach 30 min. • Start auf www.sonymusic.de liefert schlechte Ergebnisse pro 30 min., weil kaum Mediendateien vorhanden sind • Start auf www.audiofind.com, wegen sehr hoher Mediendichte • HTML-Index-Terme 7628/30 Min. (254/Min.) • Medien-Index-Terme 6148/30 Min. (205/Min.) • Indexgröße 4,228 MB/30 Min (141 kB/Min.) • Quantität des Suchergebnisses • zu korrekten Anfragen werden immer Ergebnisse geliefert, wenn sie denn im Index enthalten sind. • Qualität des Suchergebnisses • Auslesen des Indexes (->DocListDump.txt ) und Vergleich mit Suchergebnissen liefert eindeutig gleiche Ergebnisse, wie erwartet.

49. Probleme und globale Verbesserungsmöglichkeiten • Parallele Bearbeitung in der Crawler-Queue zur Geschwindigkeitssteigerung • Puffer zwischen Parser und Indexierer , weil der WebParser wesentlich schneller als der indexer ist. • Aktualisierung des Indexes (veraltete Daten löschen) ist nur manuell möglich durch die Vectorliste

50. And Now :Online - Test