next »

[cyberman]

Hallo Forum,

nichts ist so gut, als dass es nicht noch besser gemacht werden kann. Auch für CMSms gibt es eine ganze Reihe an Möglichkeiten, die Performance zu optimieren. Diese werden im folgenden näher erläutert:

HINWEIS: Wenn in einem Optimierungs-Tipp auf eine bestimmte Zeile im Quellcode verweist, kann sich diese unter Umständen in einer neuen Version von CMSms bereits geändert haben - also genau hinschauen!

C wie config.php

Hierarchische URLs

Seit Version 0.13 kann CMS made simple die URLs entsprechend der Seitenstruktur hierarchisch anzeigen, also zum Beispiel so

http://www.webseite.de/uebergeordnete_seite/untergeordnete_seite

Dies sieht zwar schön aus, kostet aber auch Performance. Schneller ist die (Standard)-Einstellung:

Code:

$config['use_hierarchy'] = false;

Persistente Verbindungen

Über die config.php kann festgelegt werden, wie CMSms sich mit der Datenbank verbinden soll. Dies erfolgt über den Parameter $config['persistent_db_conn']. Standard ist false.

Persistente Verbindungen sind SQL-Verbindungen, die nach Abarbeitung des Skriptes nicht geschlossen werden. Wird eine persistente Verbindung angefordert, prüft PHP, ob bereits eine identische persistente Verbindung (die vielleicht vorher offen geblieben ist) existiert und benutzt sie in diesem Fall. Sollte keine Verbindung existieren, wird eine hergestellt.

Daher kann die folgende Einstellung zur Beschleunigung beitragen:

Code:

$config['persistent_db_conn'] = true;

Weitere Informationen: http://www.php-resource.de/manual.php?p=features.persistent-connections

ACHTUNG: Dieser Wert wird nicht von allen Providern erlaubt und kann zu Problemen führen.

"Schöne" Pretty URLs

Hier gilt das gleiche wie bei der Option "Hierarchische Seitenanzeige". Die schnellste Einstellung ist auch hier der bereits vorgegebene Systemstandard:

Code:

$config['internal_pretty_urls'] = false;

HINWEIS: Damit die Änderungen an der config.php wirksam werden, MUSS der Zwischenspeicher gelöscht werden (Administration, Menü 'Administrator > Globale Einstellungen').


C wie contentcache.php

Vor einiger Zeit wurde die Datei contentcache.php eingeführt, die im Verzeichnis /tmp/cache angelegt wird. Darin ist serialized die Hierarchie aller Inhalte einer Webseite enthalten. Das sollte eigentlich zu einer Beschleunigung führen, tut es aber nicht.

Um die Erstellung der Datei zu deaktivieren, muss in der Datei class.contentoperations.inc.php aus dem Verzeichnis /lib/classes/ die Zeile 497 von

Code:

$usecache = true;

auf

Code:

$usecache = false;

geändert werden.

Quelle:  http://forum.cmsmadesimple.org/index.php/topic,7645.0.html


E wie Erweiterungen

CMS made simple wird durch Module (Verzeichnis /modules, siehe Administration, Menü 'Erweiterungen > Module') und Tags (Verzeichnis /plugins, siehe Administration, Menü 'Erweiterungen > Tags') erweitert.

Es gibt gute Gründe, ein Modul für eine bestimmte Aufgabe einzusetzen. Wenn man aber die Auswahl hat, entweder ein Modul oder einen Tag einzusetzen, ist der Tag die schnellere und ressourcenschonendere Lösung.

Ein gutes Beispiel dafür ist ein Kontaktformular. Dafür kann entweder das FormBuilder- / das FeedbackForm-Modul verwendet oder aber der contact_form-Tag modifiziert werden.


I wie index.php

Komprimierung des Outputs

Wenn euer Provider zip-Unterstützung bietet (was sich mit dem phpinfo()-Befehl leicht herausfinden lässt), dann ist die folgende Änderung schon fast Pflicht:

Öffnet die Datei index.php in einem Editor und geht dort zu Zeile 35. Dort sollte etwas in dieser Art stehen:

Code:

@ob_start();

Je nach Serverausstattung ist die Datei wie folgt zu ändern:

Code:

@ob_start('gzhandler');

Code:

@ob_start('ob_gzhandler');

Code:

@ob_start('gz_handler');

Einfach ausprobieren ...

Was genau passiert da? Der Server wird angewiesen, jede Datei mit dem zip-Kompressionsalgorithmus zu komprimieren und erst dann zu versenden. Die komprimierte Datei wird dann vom Browser wieder entpackt und angezeigt. Aufgrund der Kompression werden die Dateien kleiner, es wird Bandbreite gespart und die Datei ist scheinbar schneller auf dem Rechner.

Auch die Administration lässt sich damit beschleunigen. Dazu muss die Datei admin/header.php mit einem Editor geöffnet und die Zeile 5 wie oben beschrieben geändert werden.

ACHTUNG: Wird das TinyMCE-Modul verwendet (welches ebenfalls die zip-Kompression verwenden kann), kann es zu Problemen kommen. Die TinyMCE-Kompression muss in diesem Fall deaktiviert werden.

Setzen des HTTP-Cache-Headers

Im HTTP-Header einer jeden html-Seite kann festgelegt werden, wie lange eine Seite im Browser des Webseiten-Besuchers gecacht/zwischengespeichert werden soll. Dieser Wert kann zum einen in der index.php eingetragen werden.

Fügt dazu hinter die Zeile 282 (CMSms 1.0.7) folgendes ein:

Code:

header("Cache-Control: public, max-age=60, s-maxage=60");

Damit wird die Seite für 60 Sekunden zwischengespeichert. Diese Werte können natürlich entsprechend den Bedürfnissen angepasst werden, was es für relativ statische Seiten besonders interessant macht.

HINWEIS: Diese Änderung empfiehlt sich nicht bei dynamisch erzeugten Seiten (Verwendung des FrontendUser- / CustomContent-Moduls u.a.).

Wer trotzdem nicht auf diese Möglichkeit verzichten möchte, kann für diesen Zweck auch individuell für jede Seite Meta-Tags einsetzen. Der entsprechende Metatag sieht wie folgt aus:


Überprüfung der Kompilierung durch Smarty abschalten

Bei jedem Aufruf der Webseite prüft Smarty, ob seit dem letzten Aufruf Änderungen am verwendeten Template vorgenommen wurden. Ist dies der Fall, wird das Template neu kompiliert, unabhängig davon welchen Wert die Variable '$compile_check' hat. Der Wert dieser Variablen ist standardmäßig 'true'.

Im produktiven Einsatz (=die Templates ändern sich nicht mehr) ist jedoch die Überprüfung der Kompilierung nicht erforderlich. Um die Performance zu steigern, muss in der index.php die Zeile 241 (CMSms 1.0.7) von

Code:

$smarty->compile_check = true;

in

Code:

$smarty->compile_check = false;

geändert werden. 

ACHTUNG: Werden nach dieser Änderung an der index.php Templates modifiziert, werden diese NICHT übernommen; der Zwischenspeicher MUSS manuell gelehrt werden (Administration, Menü Administrator > Globale Einstellungen).

Quelle: http://smarty.php.net/manual/de/variable.compile.check.php


M wie Module

CMS made simple wird mit 8 Modulen ausgeliefert. Diese befinden sich im Ordner /modules und werden durch die Installationsprozedur automatisch installiert. Beim Start von CMSms (=Besuch der Webseite) werden alle Module geladen.

Aus diesem Grund sollten alle nicht benötigten Module deinstalliert (oder noch besser, erst gar nicht mit auf den Server geladen ) werden.

Dazu ein paar Entscheidungshilfen:

CMSmailer

Dieses Modul stellt die Funktionen des PHPMailers

http://phpmailer.sourceforge.net/

für CMSms-Module bereit. Zum Beispiel wird es vom Modul Guestbook verwendet, um nach Erstellung eines neuen Eintrages eine Benachrichtigungen an den Administrator zu versenden.

Beim mitgelieferten Tag {contact_form} erfolgt der Mailversand über die php-eigene mail()-Funktion. Das CMSMailer-Modul wird in diesem Fall nicht benötigt und kann deinstalliert / gelöscht werden.

ModulManager

Mit diesem Modul wird ein zentrales Verzeichnis abgefragt, welche Module als XML-Datei importiert werden können und anschließend als Liste angezeigt. Die Module können dann direkt installiert und aktualisiert werden.

Bei manchen Betriebssystem mögen ja häufige Updates zwingend erforderlich sein. Für ein CMS im produktiven Einsatz ist dies jedoch nach meinem Verständnis flüssiger als Wasser – nämlich überflüssig und kann/sollte daher deinstalliert / gelöscht werden.

HINWEIS: Diese Funktionalität wird nicht von jedem Hoster erlaubt. Außerdem wird mit dieser Art des Imports der Server Eigentümer der Dateien. Dies hat zur Folge, dass beim Zugang via FTP o.ä. diese Dateien nicht angezeigt werden (fehlende Berechtigung).

Wer trotzdem Gefallen am Import von Modulen als XML-Datei gefunden hat (ohne FTP-Zugang), kann diese auch ohne den ModulManager verwenden; einfach die XML-Datei lokal auf dem Rechner abspeichern und dann via Administration (Menü 'Erweiterungen > Module') auf den Server laden.

NuSOAP

Dieses Modul stellt die SOAP-Funktionen für CMSms-Module bereit. SOAP (ursprünglich für Simple Object Access Protocol) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können.

Quelle/weitere Informationen: http://de.wikipedia.org/wiki/SOAP

Diese Funktionalität wird nur von ModulManager benötigt. Wer diesen bereits deinstalliert/gelöscht hat, kann auch dieses Modul entfernen.

ThemeManager

Mit dem ThemeManager lassen sich Templates als .xml-Datei ex- und importieren. Diese Datei enthält alle benötigten Daten (Templates, Stylesheets, Bilder, Javascripts). Da auf einer Seite im produktiven Einsatz die Templates nur selten gewechselt werden, kann das Modul deinstalliert / gelöscht werden.


M wie MySQL

Auch MySQL kennt Methoden, um die Kommunikation mit der Datenbank zu komprimieren und damit zu beschleunigen. Dies wird auch vom in CMSms eingesetzten Datenbank-Layer AdoDB lite unterstützt.

Aktiviert wird die Kompression wie folgt:

1. Die Datei /lib/adodb.functions.php mit einem Editor öffnen
2. Zur Zeile 56 gehen (CMSms Version 1.0.5)

Code:

$dbinstance =& ADONewConnection($config['dbms'], 'pear:date:extend:transaction');

3. Die folgende Zeile einfügen

Code:

$dbinstance->clientflags = MYSQL_CLIENT_COMPRESS;

4. Abspeichern


S wie Serverwahl

Wenn ihr die Auswahl hab, ob eure Seite unter einem Apache Server/Linux oder unter IIS/Microsoft laufen soll, lautet die Empfehlung ganz klar Apache/Linux. Bilder sagen mehr als Worte:

http://blogs.zdnet.com/threatchaos/?p=311

Ist zwar in englisch, aber die Bilder zeigen das wichtigste, nämlich die erforderlichen System-Aufrufe des Apache und des IIS. Ergo, bei diesem "Strickmuster" kann IIS nicht schneller als der Apache sein  .


S wie Server-Optimierung

Neben den hier genannten Möglichkeiten der CMSms-"internen" Optimierung kann auch eine Optimierung des Servers selbst eine erhebliche Beschleunigung bewirken:

Apache-Modul mod_cache

Über dieses Modul werden die Ausgaben des Servers in einem Zwischenspeicher abgelegt und stehen daher schneller zum Abruf bereit. Der Einsatz dieses Moduls kann das System um 20-40 % beschleunigen. Weitere Infos dazu gibts hier

http://httpd.apache.org/docs/2.0/mod/mod_cache.html

Der Dank geht an PierreM.

Apache-Modul mod_expires

Auch via .htaccess-Datei lassen sich auch bestimmte Elemente wie etwa Bilder, CSS und JavaScript cachen. Hier dazu ein Beispiel:

Code:

ExpiresActive on
ExpiresByType image/gif "access plus 6 months"
ExpiresByType image/jpeg "access plus 6 months"
ExpiresByType image/png "access plus 6 months"
ExpiresByType text/css "access plus 6 months"
ExpiresByType text/javascript "access plus 6 months"
ExpiresByType text/html "access plus 1 day"
ExpiresByType application/x-javascript "access plus 6 months"

<Files ~ "\.(js|css|gif|jpg|png)$">
Header append Cache-Control "public"
</Files>

Weitere Infos dazu gibts hier

http://httpd.apache.org/docs/2.0/mod/mod_expires.html

Mit dem folgenden Link kann geprüft werden, welche Bedingungen für das Cachen von Elementen gesetzt werden könnten

http://www.ircache.net/cgi-bin/cacheability.py

Der Dank geht an faglork.

Und hier noch ein Link zum Verständnis des Cachens/Zwischenspeicherns (englisch)

http://www.mnot.net/cache_docs/

eAccelerator

Wer CMSms auf einem eigenen Server/vServer bzw. Zugriff auf die Installation hat oder sich mit dem Admin gut versteht, sollte sich diese Erweiterung mal näher anschauen

http://eaccelerator.net/

Damit werden vereinfacht gesagt die PHP-Scripte optimiert und zwischengespeichert, um deren Abarbeitung zu beschleunigen und den Server zu entlasten. Hiermit sind nach Angaben des Autors Beschleunigungen bis zum Faktor 10 möglich.

Zend Optimizer

Ähnlich wie der eAccelerator, nur 'ne Nummer größer. Wer sich für seine CMSms-Seite einen eigenen Server/vServer gönnt, kommt am Zend Optimizer für den Apache Webserver nicht vorbei 

http://www.zend.com/de/downloads


S wie Smarty

Smarty, die von CMSMS eingesetzte Template-Engine, bringt auch eine ganze Reihe von nützlichen Erweiterungen/Plugins mit. Diese sind im Verzeichnis /lib/smarty/plugins zu finden. Häufig führen sie ein Schattendasein, werden aber bei jedem Start von CMSms mit abgefragt.

Soweit ihr nicht Module verwendet, die bestimmte Tags aus diesem Verzeichnis benötigen (wie zum Beispiel das News-Modul), wäre das Löschen dieser Tags noch ein Optimierungspotential.

Aber VORSICHT - ihr solltet hier sehr genau wissen, was ihr tut.


T wie Tags

Von dem Problem, über das bereits im Abschnitt „Module“ gesprochen wurde, sind auch die Tags betroffen. Beim Start wird das komplette /plugins-Verzeichnis gelesen. Daher empfiehlt es sich, auch hier nur die benötigten Tags in dem Verzeichnis zu belassen. Hier ist es schwieriger, konkrete Empfehlungen zu geben, da jeder einen anderen Bedarf hat.

Im folgenden hab ich mal eine Hitliste meiner persönlichen „Löschkandidaten“ erstellt, die ich nicht bzw. selten verwende:

function.adsense.php
function.bulletmenu.php
function.cms_version.php
function.cms_versionname.php
function.edit.php
function.embed.php
function.google_search.php
function.googlepr.php
function.html_blob.php
function.image.php
function.ImageGallery.php
function.valid_css.php
function.valid_xhtml.php

Tags, die nur bei Bedarf vorhanden sind:

function.contact_form.php
function.created_date.php
function.current_date.php
function.description.php
function.last_modified_by.php
function.menutext.php
function.modified_date.php
function.recently_updated.php
function.sitemap.php
function.sitename.php

U wie use_sub_dirs

Für die folgende Optimierung muss die Datei admin/lib/content.functions.php Zeile 54/55 bearbeitet werden:

Code:

//use_sub_dirs doesn't work in safe mode
//if (ini_get("safe_mode") != "1")
//  this->use_sub_dirs = true;

wird geändert in

Code:

//use_sub_dirs doesn't work in safe mode
if (ini_get("safe_mode") != "1")
  this->use_sub_dirs = true;

Diese Einstellung sollte individuell ausgetestet werden, da dies nicht auf jedem Server funktioniert.


Ü wie Übersetzungen

CMS made simple ist gegenwärtig in 33 Sprachen verfügbar, die bei der Installation mitgeliefert werden. Das wäre grundsätzlich kein Problem, wenn nicht auch die Übersetzungen (wie bereits die Module) beim Start einer Webseite komplett geladen würden.

Im Laufe der Entwicklung ist die Verzeichnisstruktur der Module mehrfach geändert worden, von /modules/ein_modul/lang/de_DE.php über /modules/ein_modul//lang/de_DE/de_DE.php bis aktuell zu /modules/ein_modul/lang/ext/de_DE.php.

In der Administration ist es ähnlich. Im Verzeichnis /admin/lang/ finden sich Dateien in dem Format de_DE.nls.php sowie im Unterverzeichnis /admin/lang/ext/de_DE die Datei admin.inc.php.

Wer nur deutsch verwendet, kann daher alle Sprachdateien außer Deutsch (und vielleicht noch Englisch) löschen.


X wie xhtml

CMS made simple ist von Natur aus ein xhtml-CMS. Daher sollte bei Templates und Inhalten darauf geachtet werden, dass sämtliche Seiten xhtml-valid ("wohlgeformt") sind.

Eigentlich logisch, dass sauberer Code schneller angezeigt wird als fehlerhafter, bei dem der Browser erst überlegen muss, was er wie anzeigen soll.

Die Überprüfung sollte immer erfolgen, da die für CMS made simple verfügbaren WYSIWYG-Editoren nicht oder nur bei bestimmten Voreinstellungen xhtml-validen Code erzeugen.

Dies kann online über den Link

http://validator.w3.org/

oder offline mit dem Browser Firefox und der Erweiterung

HTML Tidy - https://addons.mozilla.org/firefox/249/

geprüft werden.


In der Summe sollte eure Seite jetzt ein ganzes Stückchen schneller sein.

[piratos]

@ob_start('ob_gzhandler');

Dieser Handler erfordert die zlib - extension und dazu auch zlib.output_compression = on und genau das ist in vielen Fällen NICHT der Fall.

Der Erfolg in solchen Fällen - eine weiße Seite. Vorher also phpinfo ausgeben lassen und nachsehen.

@ob_start('gzhandler');

funktioniert jedoch in den meisten Fällen.

[piratos]

Beim Start wird das komplette /plugins-Verzeichnis gelesen

Es genügt auch die Plugins  von \plugins nach  \lib\smarty\plugins zu verschieben. Dann allerdings ist die Tag - Hilfe im Adminbereich futsch.

[SimonSchaufi]

Ich hab mal ein PHP Skript geschrieben, das alle unbenötigten Sprachdateien löscht. skript auf anfrage!

I have written a PHP Script to delete all unnecessary language files. You can get the script if you contact me!

[RonnyK]

Cyberman,

mal ein kurze Frage, diese Topic heist "...Tuning 1.0.x". Funktioniert der auch fur 1.1 oder gibts dafur ein andere....

Ronny

[cyberman]

Hi Ronny,

hab noch nicht alles gecheckt, aber ein Großteil der Empfehlungen gilt auch für die 1.1 ...

[NaN]

Apache-Modul mod_expires

Auch via .htaccess-Datei lassen sich auch bestimmte Elemente wie etwa Bilder, CSS und JavaScript cachen. Hier dazu ein Beispiel:
...

Also wenn ich diesen Code in meine .htaccess-Datei reinschreibe kommt beim Seitenaufruf immer

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

 

[cyberman]

Bist du dir sicher, dass das Apache-Modul mod_expires geladen wurde?

[NaN]

Bist du dir sicher, dass das Apache-Modul mod_expires geladen wurde?

Keine Ahnung. Hab keinen Zugriff auf die "httpd.conf" Datei. Bin einfach mal davon ausgegangen. Kann man sowas beim Provider erfragen?

Mit dem folgenden Link kann geprüft werden, welche Bedingungen für das Cachen von Elementen gesetzt werden könnten

http://www.ircache.net/cgi-bin/cacheability.py

Na besten Dank. Sei dem ich das gemacht habe, sieht meine Seite aus wie vor 15 Jahren.   

Die Stylsheets werden so gut wie gar nicht mehr interpretiert und Hintergrundgrafiken gibts auch nicht mehr. 

Kann mir zwar nicht vorstellen, dass das an dem ircache-Link liegt (die testen doch nur was, oder?), aber das war das Letzte was ich gemacht habe bevor der Fehler aufgetreten ist.

Cache hab ich schon tausendmal gelöscht.

Ich krieg langsam ne Krise. Offline funktioniert immer alles einwandfrei. In 9 (!) Browsern getestet. Und kaum ist die Seite online... 

Ich hab das Gefühl, ich bin was die ganze Servertechnik angeht nicht ganz auf dem Laufenden.

Könnte es eventuell an der CMSms Version 1.2 liegen?

Und wie kriege ich die Seite wieder hin?   

Edit: Hab gerade festgestellt, dass der Fehler nur im FIREFOX auftritt.  Jetzt versteh ich die Welt nicht mehr.

[cyberman]

Hab keinen Zugriff auf die "httpd.conf" Datei.

Oder php.ini

Kann man sowas beim Provider erfragen?

Kannst du auch selbst machen - erzeug dir einfach mal einen benutzerdefinierten Tag (oder eine simple php-Datei) mit phpinfo(); als Inhalt und ruf den Tag im Content auf (oder eben die Datei solo).

(die testen doch nur was, oder?),

Yep.

Könnte es eventuell an der CMSms Version 1.2 liegen?

Die 1.2 gibt es (noch) nicht - du meinst sicherlich 1.1.2

Edit: Hab gerade festgestellt, dass der Fehler nur im FIREFOX auftritt. 

Hast du auch mal den Firefox-Cache gelöscht?

[NaN]

Hast du auch mal den Firefox-Cache gelöscht?

Ja hab ich. Ich hab sogar den Rechner gewechselt. (hier stehen 30 Stück...)

Die Seite sieht fast so aus, als hätte ich die Stylesheets beim FF deaktiviert.

Ich gehe über einen Server der Uni bei mir ins Netz. Könnte es daran liegen, dass dort evtl. eine unvollständige Version der Seite "gecached" ist?

Allerdings verstehe ich dann nicht, wieso es im IE funktioniert.

[cyberman]

Könnte es daran liegen, dass dort evtl. eine unvollständige Version der Seite "gecached" ist?

Hmm, hat der Uni-Server noch einen Proxy?

Hast du mal versucht, den no cache Metatag im head zu verwenden?

[Sonya]

Danke schön für die Anleitung. Sehr übersichtlich und verständlich geschrieben und ist ein Muß beim Performance-Tuning.

Ich wollte nur Anmerkung, dass das Abschlaten der Kompilierung durch Smarty

Code:

$smarty->compile_check = false

aus irgendeinem Grund bei mir zum Session-Problem geführt hat. Bei jedem Aufruf der Seite wurde neue php Session angelegt und es führte dazu, dass Session Variablen nicht mehr verfügbar waren. Server: Linux Debian/Apache 1.3.

[cyberman]

Danke für den Hinweis - unter welcher Konstellation tritt bei dir das Problem auf (CMSms, Module, Tags - Versionen)?

[Sonya]

Danke für den Hinweis - unter welcher Konstellation tritt bei dir das Problem auf (CMSms, Module, Tags - Versionen)?

Ah ja, da war doch was   
CMS Made Simple 1.2.2 "Holetown"
FrontEndUsers   1.3.1
und ein UDT

Code:

global $gCms;
$feusers =& $gCms->modules["FrontEndUsers"]["object"];
if ($feusers->LoggedIn()) {
   $_SESSION['logged_feuser'] = .......;
} else {
   unset($_SESSION['logged_feuser']) ;
}

Genau dieses UDT geht "kaputt", die Session variable geht verloren mit compile_check = false und ist verfügbar mit compile_check = true.

Ich werde noch etwas weiter forschen, vielleicht finde ich die Ursache.