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

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

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

Das Wichtigste ist : 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 2 Buchstaben übergangen.

Unsere Suchmaschine ist gegenüber unserem "Content Management System" "typo3" autark und sie funktioniert auf der Linux Ebene, auf der Betriebssystem- Ebene. Sie ist aber in unser typo3 "CMS" auf 2 Ebenen mit mehreren PHP-Programmen voll integriert.

Einmal ist das der Indexer, der Nachts auf Linux-Ebene die 256 Indextabellen der mysql Datenbank füllt und dann gibt es die spezielle typo3 Erweiterung, die die Treffer einer Suche sammelt und richtig handlich und übersichlich auf den Ergebnisseiten aufbereitet und farblich markiert 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 (Erweiterungen) "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 sie fressen auch die Kraft mehrerer CPUs auf und die haben wir (zur Zeit) 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 3 Minuten zum ersten Treffer.

Die aktuelle "Online"-Suchmaschine "lucene" läuft auch auf dem Linux-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 "mnoGoSearch" offline Datenbank wird von der sogenannten Engine in einem offline-Durchlauf in unserer mysql Datenbank ein auf 255 Tabellen verteilter Binär-Baum- (ein B-Tree-) Index erstellt, der nach dem Durchlauf des Indexers sofort sämtliche Wörter in einer exzellenten Geschwindigkeit verfügbar hat.
.

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: 20.301 (0.081 Sekunden)
• Anzeige Treffer 1-10 von 2598. Seite 1 von 260.

.
oder "stereo"
.

• Treffer - stereo: 20965 (0.031 Sekunden)
• Anzeige Treffer 1-10 von 1665. Seite 1 von 167.

.

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 (für diese "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 und dennoch sehr schnell ist.

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, im sogenannten RAM. Das sind die steckbaren Speicherstreifen mit (zur Zeit) 2 oder 4 GB je Streifen.

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 inzwischen 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.
.

.