Oflfline heißt, in periodischen Abständen lädt ein sogenannter Crawler aus einer "Website" ab der Startseite der Domain die über ein Menü oder eine "TOC"- Tabelle (= table of content) verlinkten Seiten dann Seite für Seite und sortiert alle dort gefundenen Wörter (oder sogar ganze Sätze) in seinen sogenannten Index ein. Bei uns heißt der Crawler deshalb auch "Indexer".  Bei den Großen merkt sich eine weitere Datenbank alle Änderungen zum letzten Besuch.

Die großen Suchmaschien wie google und bing und andere kommen bei uns Woche für Woche in der (europäischen) Nacht "vorbei" und indizieren unsere Seiten nach ihren Regeln.
.

Unsere eigene Suchmaschine ist eine viel viel einfachere und nur Bruchteile dieser Funktionen umfassende Variante - aber mit einigen Vorzügen für unseren Bedarf.

Auf unserem Server bestimme ich die Regeln. Da wird "niemand" (also keine Seite) bevorzugt oder ausgeschlossen. Auch bei uns baggert der Indexer alle Seiten von vorne bis hinten durch - mit maximaler Prozessor-Geschwindigkeit. Weiterhin werden bei uns alle Wörter mit nur 3 Buchstaben und noch kürzer übergangen.

Unsere Suchmaschine ist eigentlich gegenüber typo3 autark und sie funktioniert auf Betriebssystem-Ebene. Sie ist aber in unser typo3 CMS auf 2 Ebenen mit mehreren PHP-Programmen voll integriert.

Einmal ist das der Indexer, der auf Linux-Ebene die Indextabellen der mysql Datenbank füllt und dann die typo3 Erweiterung, die die Treffer einer Suche richtig handlich und übersichlich aufbereitet und auf den Ergebnisseiten darstellt.

Diese Integration dieser freien "mnoGoSearch Engine" hatte damals der typo3 Spezialist Dmitry Dulepov programmiert. Und damit haben wir ein Werkzeug, unsere Inhalte in dieser erheblich gewachsenen Menge zeitnah (also "beinahe" online) - zum Beispiel auf Rechtschreibfehler - zu überprüfen.
.

Für das CMS typo3 gab und gibt es mehrere adaptierte bzw. integrierte Suchmaschinen, sogar mehrere Online- Suchmaschinen. Die laufen alle auf der Betriebssystem-Ebene (meist LINUX) und sind an das typo3 Grundsystem als Extension angeflanscht.

Im Hinblick auf meine Forderung, die Seiten- Abruf- Geschwindigkeit des Servers immer mit Priorität zu bertrachten, scheiden die Online Suchmaschinen bereits aus. Solche Techniken fressen nicht nur Speicher ohne Ende sondern auch die Kraft mehrerer CPUs auf und die haben wir nicht.

Die uralte System-Suchmaschine im typo3 CMS ist eine recht simple und langsame "Online"- Suchmaschine, die mit dem "Suchschlüssel in der Hand" die Content-Datenbank sequentiell durchforstet und dann die Treffer auflistet. Am Anfang vor 20 Jahren ging das alles super schnell, doch heute bei fast 48.000 Seiten dauert es (gefühlt) ewig - bis zu 5 Minuten zum ersten Treffer.

Die aktuelle "Online"-Suchmaschine "lucene" läuft auch auf dem Server, baut sich aber erst während der Abfragen und der dann als Folge ausgelieferten Seiten einen Index auf, der natürlich nur teilaktuell ist. Bei jeder neuen Abfrage muß die Engine prüfen, ob die Seite bereits einsortiert ist und/oder sich die Inhalte geändert haben. Das ist schwerfällig, fordert modernste Mehrkern-Prozessoren und verzögert den Ablauf.

Bei der offline Datenbank "mnoGoSearch" wird von der Engine offline in unserer mysql Datenbank ein auf 255 Tabellen verteilter Binär-Baum- (ein B-Tree-) Index erstellt, der nach dem Durchlauf des Indexers sofort in einer exzellenten Geschwindigkeit verfügbar ist.
.

Wieder nehmen wir bewußt ein simples erstes Beispiel - den Namen "grundig".

Als Ergebnis der Suche bekomme ich diese Zeilen :

• Treffer - grundig: 5.182 (0.017 Sekunden)
• Anzeige Treffer 1-10 von 929. Seite 1 von 93.

oder "magnetabtaster:"

• Treffer - magnetabtaster: 16 (0.024 Sekunden)
• Anzeige Treffer 1-10 von 11. Seite 1 von 2.

oder "hifi"
.

• Treffer - hifi: 19.762 (0.085 Sekunden)
• Anzeige Treffer 1-10 von 2598. Seite 1 von 260.

.
oder "stereo"
.

• Treffer - stereo: 205.65 (0.031 Sekunden)
• Anzeige Treffer 1-10 von 1605. Seite 1 von 161.

.

Die Antwort-Geschwindigkeit unseres Servers ist atemberaubend - zum Beispiel : 0,017 Sekunden für 929 Treffer. Und in unserem Museen-Server werkelt zur Zeit "nur" ein Intel i5 Prozessor mit 4 Kernen und 3,2 GHz und 4 GB Speicher (als VM = virtuelle Maschine). Geplant ist ein Upgrade auf einen gebrauchten i7 Prozessor mit 8 Kernen oder gar einen Ryzen mit 12 Kernen. Ganz erstaunlich ist, daß die Anbindung ans Internet zur Zeit (April 2024) über unsere Fritz-Cable Box nur 10 Mbit/s beträgt.

Im Protokoll des Indexers lese ich - heute Mittag (im April 2024) zum Beispiel :

hifimuseum - Start at :   Sa 27. Apr 12:16:27 CEST 2024
Indexer fertig am           Sa 27. Apr 14:50:21 CEST 2024
.
... also die Indexer-Laufzeit dauerte von 12.16 bis 14.50 = etwa 2 1/2 Stunden

Beim nächtlichen Indizieren bekomme ich weitere Informationen, so zum Beispiel, daß der Indexer über 100 Millionen Sorts vorgenomen hatte.

Ganz am Ende kommen als Letztes diese Zeilen :
.................................
[24704]{01} Writing words (121.586 words, 3.688.867 bytes, final).
[24704]{01} The words are written successfully. (final)
[24704]{01} Done (8.473 seconds, 33.361 documents, 203.523.236 bytes, 23.46 Kbytes/sec.)

Solche Meldungen werden während des Indizier-Vorganges über 8 Mal ausgegeben, weil der Indexer den Binär-Tree erst temporär im Speicher aufbaut und dann blockweise (oder schubweise) in die Index-Tabellen schreibt.

Der Indexer hat damit in den 2 1/2 Stunden über 200 Megabyte an sortierten Binärdaten in diese Tabellen geschrieben.

Und das  hier kommt dann ganz zuletzt aus unserem Script, der den Indexer aufruft :

====== der Indexer ist fertig !!!!!
====== Die mnogosearch Tabellen fuer  hifimuseum_content  sind jetzt wieder voll
.
Auf der Such-Seite der Museen-Suchmaschine können Sie das alles ausführlich testen.

.

Warum machen wir das und was verstehen wir unter Aktualisierung ?

Das Linux Betriebssystem beschleunigt viele Dienste und Funktionen mit einem ausgeklügelten sogenannten "Caching". Unter "Cachen" verstehen wir das temporäre Speichern von Programmen (oder Teilen davon) mitsamt Texten und Bildern im Hauptspeicher. Mit dieser Caching-Funktion werden (erneut) abgefragte Webseiten direkt aus dem Hauptspeicher geladen und nicht von der deutlich langsameren Festplatte. Das gilt auch für die etwas schnelleren SSD's (das sind Halbleiter Festplatten), die immer noch etwas langsamer sind als der Hauptspeicher. Die Verwaltung bzw. die Aktualisierung dieses Cache-Speichers übernimmt das Betriebssystem.
.
Unser "Content Management System" typo3 beinhaltet ein weiteres eigenes Caching-Konzept. Und dann könnte man für die in PHP5 oder PHP7 geschriebenen Programme ebenfalls ein (drittes) Caching aktivieren, was wir aber nicht gemacht haben.
.

Diese Fnnktion ist von der Software- und Ablauf-Logistik überhaupt nicht trivial und wird so beschrieben :

Am wirkungsvollsten ist das Bilder-Caching. Von fast jedem in den Museen-Web-Seiten vorkommenden Bildern wird ein Thumbnail- (ein Daumennagel-) Bild benötig, das auf der jeweiligen Web-Seite eingebunden ist. Im Normalfall werden diese kleinen Bildchen erst dann (in einem temporären Verzeichnis) erzeugt, wenn die Web-Seite zum ersten Mal abgerufen wird.

Weiterhin : Normalerweise werden alle Web-Seiten beim ersten Abfruf mit allen Content-Elementen aus der Datenbank und aus den Verzeichnissen zusammengesucht und gestalterisch "montiert" und als eine komplette Seite ausgeliefert.

Gleichzeitig werden diese abgerufenen Web-Seiten in großen Caching-Tabellen in der aktuellen bereits zusammengesammelten Version zwischengespeichert. Wird also eine Web-Seite zum zweiten (=wiederholten) Male abgerufen, kommt sie extrem schnell aus diesen Caching-Tabellen und muß nicht nochmal zusammengesucht werden. Das spart sehr viel Zeit und Server-Leistung.

Bei jeder Änderung eines in solch einer Seite enthaltenen Content-Elements wird die alte gecachte Seite komplett verworfen und eine neue angelegt. Damit wachsen diese Caching-Tabellen natürlich ins Uferlose. Regelmäßiges Bereinigen von Hand ist mühsam. Das alles macht deshalb unser Indexer-Script.
.

Mit dem Aufruf des Indexers der mnoGoSerch Suchmaschine (also unseres Scripts) werden alle Caching-Tabellen von typo3 und die Index-Tabellen der Engine sowie die Temp-Verzeichnisse geleert (nicht gelöscht !!).

Beim Reindizieren dann werden alle Web-Seiten (unsichtbar im Hintergrund auf dem Server) komplett einmal geladen und damit werden die Caching-Tabellen neu gefüllt und auch diese kleinen Bildchen auf Vorrat erzeugt. Von da an laden alle Web-Seiten auch beim ersten externen Abruf sehr sehr schnell.
.

Solche Caching Prozeduren, auch verknüpfte oder verkettete Caching-Systeme, haben ihre Grenzen, wenn die "Tasks" kollidieren und eine Caching Prozedur eine andere "austrickst" oder unterminiert. In den neueren CMS Versionen von typo3 wurde das typo3 System immer langsamer - bei den gleichen Inhalten in den Content-Elementen. Wir haben nie herausgefunden, warum das so war.

Der leider heutzutage unpassende "Spruch" (oder "Ratschlag" ?) der Entwickler, man solle dann eben leistungstärkere Prozessoren und deutlich mehr Hauptspeicher einsetzen, kontakariert jeden zwingend notwendigen Umweltgedanken und jede Stromspar-Vorgabe.

Nach den letzten Abruf-Tests unserer Seiten aus den USA aus Sakramento und aus Miami (Dez. 2023) wurde uns eine exzellente "Übersee"-Abruf-Geschwindigeit attestiert.

Das bedeutet doch, unser jetziges Server-Konzept funktioniert weltweit absolut zufriedenstellend.
.