CMS Fiona, der verwendete Webserver und auch die meisten Datenbanken können so konfiguriert werden, dass sie die Systemressourcen besser nutzen.
Die in diesem Abschnitt genannten CMS-Einstellungen können in der Konfigurationsdatei tuning.xml vorgenommen werden.
Die Datenbank ist in Bezug auf die Performance des CMS eine kritische Komponente, weil sowohl das Redaktionssystem (d.h. der Content Management Server) als auch der Export (d.h. die Template Engine) auf sie zugreifen.
Der Content Management Server bedient die Anfragen der Benutzer des GUIs. Damit die Wartezeit für Redakteure möglichst kurz ist, startet ein Master-Server eine konfigurierbare minimale und maximale Anzahl Slaves. Jeder dieser Slaves verarbeitet eine ebenfalls konfigurierbare Anzahl Anfragen und wird dann vom Master-Server bei Bedarf (wenn weitere Anfragen vorliegen) durch einen neuen Slave ersetzt. Jeder dieser Slaves baut eigenständig Datenbankverbindungen auf.
Auch der Export wird von einer konfigurierbaren Anzahl Slaves parallel durchgeführt, von denen jeder seine eigene Datenbankverbindung aufbaut.
Ob die Datenbank tatsächlich so viele Verbindungen zu den Slaves des Content Management Servers und der Template Engine handhaben kann, hängt zum einen von der Datenbank-Lizenz ab. Die Lizenz beschränkt in der Regel die maximale Anzahl Verbindungen.
Zum anderen wird die Anzahl der effizient nutzbaren Datenbankverbindungen durch das verfügbare RAM (bei Memory-Access) oder die Netzlast (bei Netzwerk-Anbindung) beeinflusst. Lokale Datenbanken sind immer performanter als über das Netzwerk angebundene.
Insbesondere Oracle-Datenbanken laufen häufig mit den voreingestellten, nicht optimalen Werten für beispielsweise die Cache-Größen. Ferner kann die Performance der Oracle-Datenbank deutlich verbessert werden, indem Control Files, Redo Log Files, Temporary Files, Rollback Files und Data Files auf unterschiedliche Platten verteilt werden. Dies gilt analog auch für Datenbanken anderer Hersteller.
Der Export ist eine rechenintensive Aufgabe, die, wie erwähnt, von mehreren Slaves durchgeführt wird. Da jeder Slave potenziell die Rechenzeit einer CPU in Anspruch nehmen kann, jedoch auch weniger rechenintensive Aufgaben erledigt (beispielsweise Dateien lesen und schreiben), sollten je CPU zwei Slaves für den Export vorgesehen werden.
Die Indizierung und die Suche sind ebenfalls rechenintensive Vorgänge. Ist der Search Server in das Redaktionssystem und auf der Live-Seite eingebunden, so werden die entsprechenden Indizes bei jeder Änderung von Inhalten aktualisiert. Im Normalfall ist die Indizierung jedoch kaum performance-relevant, weil Inhalte weit seltener hinzugefügt als angefordert werden (außer beim ständigen Upload großer Datenmengen).
Werden über die Live-Seiten viele Suchanfragen gestellt, so lässt sich die dadurch erzeugte Last durch schnellere oder weitere CPUs sowie schnellere Massenspeicher abfangen.
Beim Live-Server ist es empfehlenswert, die Anzahl der vorgehaltenen Prozesse zu erhöhen, wenn die Requests nicht schnell genug beantwortet werden können.
Enthält die Website viele dynamische Komponenten wie PHP- oder Java-Seiten, so erhöht dies den Bedarf an Rechenzeit, die durch eine schnellere oder weitere CPU zur Verfügung gestellt werden kann. Dies gilt auch und in höherem Maße beim Einsatz von SSL, da die Verschlüsselung ebenfalls rechenintensiv ist.
Gern übernimmt JustRelate im Rahmen Ihres CMS-Fiona-Projekts die Optimierung der von Ihnen eingesetzten Datenbank oder des Trifork Application Servers.