Hi Andreas,

Welches Ranking?
wie wÃrs mit dem Datum?

die Indexdateien werden bereits so sortiert, daà die Treffer in umgekehrter Reihenfolge der Entstehung der Postings gefunden werden.
Diese Art des "Ranking" ist also schon im Indexer vorhanden - die Suchfunktion selbst tut da nichts mehr.

wenn ich nicht irre war die Suche in PERL
geschrieben, oder? Alle paar Sekunden eine 106 MB
groÃe Textdatei zu parsen, das ist doch Wahnsinn!

Das ist die RealitÃt. ;-)
Schau Dir die angegebenen CPU-Zeiten an - so schlimm ist das gar nicht.

Das Forum, welches mit noch hÃherem Aufwand die (allerdings kleineren) Thread-Dateien parsed, wird fÃnfzehnmal so oft aufgerufen wie die Suche - und das kostet auch ganz schÃn viel Last.
Insofern finde ich es auch richtig, daà Christian dort ansetzt und den Kern in einer grundsÃtzlich anderen Architektur neu schreibt - _das_ wird ein Quantensprung werden, wenn es mal stabil lÃuft.

Sicher, funktionieren tut das, aber eine DB ist
genau darauf optimiert und erledigt das ganze mit C
oder C++.

Die Sprache fÃr das biÃchen HTML drum herum ist vÃllig egal - nur die Sucherei kostet.
Meine Suchmaschinen hier im BÃro sind auch alle in Perl geschrieben und nicht in C.

Ich merke das schon wenn ich 1 MB parse mit PHP,
gut, ich kann das nicht so wie Ihr optimieren,

Machst Du denn eine entsprechende Schwachstellenanalyse? (CPU-Zeit-Messung fÃr jeden einzelnen Schritt Deines Programms.)

FÃr die Archiv-Suche gibt es in deren Dokumentation ein Kapitel, welches fÃr jeden einzelnen Schritt die relative CPU-Last innerhalb des Such-Vorgangs beschreibt - und die 100 MB zu lesen ist noch nicht mal der grÃÃte Anteil, wenn ich das richtig in Erinnerung habe (das Splitten der Felder ist ziemlich teuer, beispielsweise - das ist aber in der Architektur des Datenformats begrÃndet. Dieses zu Ãndern hÃtte bedeutet, auch den Schwanzabschneider umzuschreiben - das war damals nicht erlaubt).

aber wenn ich dieselbe Information aus der DB hole
ist das erheblich schneller

Das Berechnen der Informationen wÃrde unter Verwendung einer baumartigen Datenstruktur sicherlich schneller gehen.
Aber (wie Dir auch eine Archivsuche hÃtte klar machen kÃnnen): Eine solche Baumstruktur ist prima geeignet fÃr eine Wort-Suche, nicht aber fÃr eine Phrasen-Suche, welche die Self-Suche bisher unterstÃtzt.
mySQL-FULLTEXT _ist_ toll, erfÃllt aber nicht die Aufgabenstellung, die bisherige Suche nachzubilden.
Und ich bin nicht befugt, Aufgabenstellungen zu definieren (oder gar abzuÃndern).

AuÃerdem kann eine DB sehr viel besser mit vielen
Anfragen gleichzeitig umgehen.

Wie kommst Du darauf?
Abgesehen davon, daà praktisch keine gleichzeitigen Abfragen vorkommen - im Mittel wird tagsÃber alle 5 Sekunden eine Suche gestartet, und die dauert deutlich weniger als 5 CPU-Sekunden. Es mag lokale Peaks geben, aber der Normalfall ist das nicht. (Christian hat ja auch einen Ãberlaufschutz bei zu vielen gleichzeitigen Such-Aufrufen eingebaut - wie oft feuert der?)

Man kÃnnte die Textdateien doch rel. einfach in
eine gaaaanz einfache MySQL-Tabelle schreiben,
schÃn mit FULLTEXT Index...,

Welche MindestlÃnge fÃr einen Suchbegriff soll die Suche erzwingen? Bei mySQL sind das 4 Zeichen - alles KÃrzere wird gar nicht erst gespeichert!

Was ist mit der eingebauten Stop-Wort-Liste? mySQL entscheidet willkÃrlich, ein paar hundert Worte fÃr insignifikant zu halten und nicht zu speichern. Das kann man mÃgen oder auch nicht ...

Ich muÃte den mySQL-Quelltext jedenfalls entsprechend anpassen und neu Ãbersetzen, um FULLTEXT fÃr meine Zwecke brauchbar zu machen.

vielleicht sollte man dafÃr mySQL 4-beta verwenden,

3.x reicht m. E. vÃllig aus. In 4.0 wird zwar einiges konfigurierbar, was bisher fest verdrahtet ist, und die Suche soll auch schneller und mÃchtiger werden ... fÃr eine reine Wortsuche ist 3.x schon sehr gut geeignet.

WÃrde mich sehr interessieren wie der Stand der
Dinge ist. Oder meinst Du das wÃre auch nicht viel
schneller?

Das wird bei groÃen Datenmengen _erheblich_ schneller! (NÃmlich logarithmisch statt linear.) Deshalb habe ich mir im BÃro ja auch angetan, den mySQL-Quelltext zu Ãndern ... mein "Archiv" enthÃlt momentan das Ãquivalent von einer Million "Postings", und die Suche ist bei Verwendung 'guter' Suchbegriffe erfreulich schnell.
Der Super-GAU sind dann natÃrlich Suchbegriffe, welche sehr viele Treffer liefern - da verliert die Indexstruktur vÃllig ihren Nutzeffekt, im schlimmsten Falle kann ihre Verwendung sogar langsamer werden als ein full table scan. Man sollte dann also nicht nach "HTML" suchen ...

Viele GrÃÃe
      Michael