Posts Tagged ‘MySQL’

WordPress – WebServer Tuning

Donnerstag, Juli 29th, 2010

In den letzten Tagen und Wochen habe ich mir immer wieder in einer freien Minute mit dem optimalen Setup eines Web-Servers beschäftigt. Ich denke, mittlerweile ist BestBlog recht performant und bietet dem Nutzer zügige Ladezeiten und schnelle Downloads.

no images were found

BestBlog wird nun schon im sechsten Jahr von mir geschrieben und natürlich auch technisch betreut. Während der ganzen Zeit habe ich natürlich mit den verschiedensten Distributionen Versuche unternommen eine performante Basis für WordPress zu schaffen.

Aus diesen Erfahrungen hat sich für mich irgendwann ergeben, dass als „Grundlage“ für den WebServer CentOS eine gute Wahl ist. Im Moment nutze ich CentOS 5.5 in der 64 Bit Version.

Diese Änderungen sind für euch allerdings nur sinnvoll, wenn ihr einen eigenen Server, virtuell oder dediziert, betreibt. Bei Hosting-Paketen können diese Änderungen von euch nicht ausgeführt werden. Die meisten bekannten Hoster verwenden allerdings genau diese Technologien um einen schnellen Aufbau eurer Seite zu gewährleisten.

Lest euch die folgenden Anleitungen genau durch und versucht euch auch dran zu halten. Die hier angegebenen Werte sind nur Erfahrungswerte und aufeinander abgestimmt. Für meine Konfiguration funktionieren diese super, was aber nicht bedeuten muss, dass ihr das gleich Ergebnis erzielt.

CentOS als WebServer:

Als Grund-Installation ist immer die „minimal Installation“ zu empfehlen. In dieser Installation ist nichts enthalten, was den WebServer nachher unnötig belasten könnte. Um aus seiner Minimal-Installation eine WebServer Installation zu machen bedarf es nur weniger Kommandos.

########################################
## CentOS 5.5 Web-Server Installation ##
##       http://www.bestblog.de       ##
########################################

su -

yum update
yum install httpd mysql mysql-server php php-gd php-mysql php-devel
yum groupinstall 'Development Tools'
/etc/init.d/httpd restart
/etc/init.d/mysqld restart

Mit diesen Kommandos wird die Installation aller für WordPress benötigten Dienste ausgelöst (Apache WebServer, MySQL, PHP mit den entsprechenden Erweiterungen).

Installiert man nun WordPress ist es voll funktionsfähig. Allerdings kommt nach kurzer Zeit bei den meisten Nutzern das Bedürfnis nach Performance-Steigerung auf. Mit ein paar einfachen Anpassungen kann man seinen Blog um einiges schneller machen, wobei eine genaue Angabe in Prozent auch bei mir nur ein Blick in die Glaskugel wäre.

Kommen wir nun zu den Möglichkeiten Apache etwas leistungsfähiger zu machen.

Apache WebServer Tuning:

Um möglichst nutzerfreundlich zu sein, kommt Apache 2 in der Standardinstallation mit einigen Modulen, die für den reinen Betrieb einer Instanz von WordPress aber nicht benötigt werden. Deswegen kann man das Laden einiger Module in der Konfiguration des WebServers unterbinden.

Die Konfiguration findet sich in folgendem Pfad: „/etc/httpd/conf/httpd.conf“

Die Zeilen, die im folgenden Schritt verändert werden beginnen mit „LoadModule“. Öffnet die oben angegebene Datei mit einem Texteditor eurer Wahl. Ich empfehle VI oder VIM. Sorg dafür, dass die Passage in der Konfigurationsdatei folgendermassen aussieht.

########################################
##    CentOS 5.5 WebServer Tuning     ##
##      http://www.bestblog.de        ##
########################################

##    LoadModule-Passage anpassen     ##
##       bis sie so aussieht          ##

# Example:
# LoadModule foo_module modules/mod_foo.so
#
# LoadModule auth_basic_module modules/mod_auth_basic.so
# LoadModule auth_digest_module modules/mod_auth_digest.so
# LoadModule authn_file_module modules/mod_authn_file.so
# LoadModule authn_alias_module modules/mod_authn_alias.so
# LoadModule authn_anon_module modules/mod_authn_anon.so
# LoadModule authn_dbm_module modules/mod_authn_dbm.so
# LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
# LoadModule authz_user_module modules/mod_authz_user.so
# LoadModule authz_owner_module modules/mod_authz_owner.so
# LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
# LoadModule authz_dbm_module modules/mod_authz_dbm.so
# LoadModule authz_default_module modules/mod_authz_default.so
# LoadModule ldap_module modules/mod_ldap.so
# LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
# LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
# LoadModule logio_module modules/mod_logio.so
# LoadModule env_module modules/mod_env.so
# LoadModule ext_filter_module modules/mod_ext_filter.so
# LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
# LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
# LoadModule dav_module modules/mod_dav.so
# LoadModule status_module modules/mod_status.so
# LoadModule autoindex_module modules/mod_autoindex.so
# LoadModule info_module modules/mod_info.so
# LoadModule dav_fs_module modules/mod_dav_fs.so
# LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
# LoadModule actions_module modules/mod_actions.so
# LoadModule speling_module modules/mod_speling.so
# LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
# LoadModule proxy_module modules/mod_proxy.so
# LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
# LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
# LoadModule proxy_http_module modules/mod_proxy_http.so
# LoadModule proxy_connect_module modules/mod_proxy_connect.so
# LoadModule cache_module modules/mod_cache.so
# LoadModule suexec_module modules/mod_suexec.so
# LoadModule disk_cache_module modules/mod_disk_cache.so
# LoadModule file_cache_module modules/mod_file_cache.so
# LoadModule mem_cache_module modules/mod_mem_cache.so
# LoadModule cgi_module modules/mod_cgi.so
# LoadModule version_module modules/mod_version.so

Bei diesem Schritt müsst Ihr sehr viele Zeilen auskommentieren. Durch das „#“ vor einer Zeile wird diese beim Laden der Konfiguration von Apache nicht gewertet und das Modul damit nicht geladen. Startet den Apache WebServer nun neu, damit die Konfiguration neu geladen wird.

Es gibt auch diverse Einstellungen, die noch angepasst werden sollten. Dazu sucht in eurer Konfiguration folgende Zeilen und ändert diese entsprechend den unten stehenden ab.

########################################
##    CentOS 5.5 WebServer Tuning     ##
##      http://www.bestblog.de        ##
########################################

##   Diverse Einstellungen anpassen   ##

KeepAlive Off

KeepAliveTimeout 2

MaxKeepAliveRequests 200

Timeout 40

#####################################
##     WebServer neu starten       ##
#####################################

su -

/etc/init.d/httpd restart

Sollte ein Fehler Apache am Starten hindern, prüft bitte erneut eure Konfiguration. Kommentiert Zeilen, die Schwierigkeiten machen bitte aus und versucht erneut den WebServer zu starten.

Ist Apache erfolgreich gestartet sollte sich schon eine kleine Steigerung der Performance zeigen, da nur die nötigsten Module geladen sind und die Abarbeitung der Anfragen schneller von Statten geht.

Um noch mehr aus Apache rauszuholen, ist es möglich die „Arbeitsprozesse“ auf seine Umgebung anzupassen. Apache lässt die Anfragen durch zwei „Module“ bearbeiten (Prefork und Worker). Die Grundeinstellungen dieser beiden Module kann man in der oben erwähnten Apache-Konfiguration ändern. Da ich auch hier keine Optimal-Werte nennen kann, die für euch richtig sind, nehme ich die Werte für einen durchschnittlich besuchten Blog.

Sucht die entsprechenden Abschnitte in eurer Konfiguration und ändert Sie wie unten beschrieben ab.

########################################
##    CentOS 5.5 WebServer Tuning     ##
##      http://www.bestblog.de        ##
########################################

##     Preforker / Worker anpassen    ##

###        Preforker Anpassung       ###

StartServers       3
MinSpareServers    3
MaxSpareServers   10
ServerLimit      50
MaxClients       50
MaxRequestsPerChild  2000

###        Worker Anpassung       ###

StartServers         2

MaxClients         150

MinSpareThreads     25

MaxSpareThreads     75

ThreadsPerChild     25

MaxRequestsPerChild  0

#####################################
##     WebServer neu starten       ##
#####################################

su -

/etc/init.d/httpd restart

Ist der WebServer neu gestartet, sind die gerade vorgenommenen Änderungen aktiv. Damit sind die Änderungen, die am Apache notwendig sind abgeschlossen. Probiert ruhig ein bisschen  mit verschiedenen Einstellungen rum, aber macht vorher ein Backup der originalen Konfiguration.

Da WordPress aber nicht nur Apache braucht um zu funktionieren, sondern ebenso auf eine MySQL Datenbank angewiesen ist, die vorher installiert wurde, gibt es auch in diesem Bereich einige Möglichkeiten die Performance zu verbessern.

MySQL Datenbank Tuning:

Auch MySQL bietet vielfältige Einstellungsmöglichkeiten. Für WordPress sind allerdings Basis-Einstellungen schon ausreichend um einen anständigen und schnellen Betrieb zu erreichen.

Die folgenden Schritte ändern nur Einstellungen für den Dienst, der die MySQL-Anfragen bearbeitet. Die Datenbank an sich wird hier nicht verändert. Allerdings habe ich schonmal zusammengefasst, wie man seine WordPress Datenbank aufräumt und optimiert.

Die Konfiguration von MySQL findet sich in folgendem Pfad: „/etc/my.cnf“

Wie schon bei Apache kann ich auch hier nur Richwerte angeben, die bei mir gut funktioniert haben.

Passt die Konfiguration so an, wie im unten stehenden Kasten beschrieben.

########################################
## CentOS 5.5 Web-Server Tuning       ##
##       http://www.bestblog.de       ##
########################################

##    MySQL Konfiguration anpassen    ##

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

key_buffer = 64M
sort_buffer = 1M
join_buffer = 1M
max_allowed_packet = 8M
max_heap_table_size = 16M
table_cache = 1024
sort_buffer_size = 8M
read_buffer_size= 1M
read_rnd_buffer_size = 768K
myisam_sort_buffer_size = 48M
thread_cache_size = 512
query_cache_type = 1
query_cache_limit = 4M
query_cache_size = 64M
tmp_table_size = 16M

## Hier die Anzahl eurer CPU's eintragen ##
thread_concurrency = 4 

max_write_lock_count = 1
low_priority_updates = 1

# Disabling symbolic-links is recommended to prevent assorted security risks;
# to do so, uncomment this line:
# symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[isamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

########################################
##           MySQL Neustart           ##
########################################

su -

/etc/init.d/mysqld restart

Nach dem Neustart von MySQL sind die Einstellungen aktiv und werden im laufenden Betrieb verwendet. Bitte passt auf, dass Ihr euch bei diesen Änderungen nicht verschreibt, sonst besteht die Gefahr, dass die Datenbank inkonsistent wird.

Nun sind Apache und MySQL angepasst und euer Blog sollte schon einen Tick schneller sein. Die Basis allerdings folgt jetzt.

WordPress ist in PHP (PHP: Hypertext Preprocessor) geschrieben. PHP bietet wie die beiden Vorgänger die Möglichkeit Fein-Tuning zu betreiben.

PHP Tuning:

Mit den Einstellungen in PHP lässt sich „subjektiv“ der größte Erfolg bei der Geschwindigkeit erzielen. Daher reichen die wenigen Änderungen an der Konfiguration schon aus um sichtbar schnellere Ladezeiten zu erreichen.

Die Konfiguration für PHP befindet sich hier: „/etc/php.ini“

Bitte folgende Zeilen suchen und entsprechend dem unteren Kasten abändern.

########################################
## CentOS 5.5 Web-Server Installation ##
##       http://www.bestblog.de       ##
########################################

##     PHP Konfiguration anpassen     ##

output_buffering = On

output_handler = ob_gzhandler

zlib.output_compression = Off

########################################
##           PHP Neustart             ##
########################################

su -

/etc/init.d/httpd restart

Diese Einstellungen modifizieren in sofern, dass der Output in komprimierter Form übertragen werden kann, was einen Vorteil bietet. Nach dem Neustart von Apache sind die Einstellungen aktiv.

Im letzten Schritt der PHP-Anpassung wird ein Tool installiert, dass sich selbst als Beschleunigung, Optimierung und Cache für dynamischen Inhalt zusammen mit PHP versteht. Das bringt dann letztendlich den größten Geschwindigkeits-Vorteil, da hier die Last von Apache und PHP genommen wird und in einen schnelleren Prozess verlagert werden kann.

Installation Eaccelerator:

Um Eaccelerator zu installieren, könnt ihr die Kommandos im unteren Kasten abschreiben. Deswegen war es wichtig, wie oben erwähnt die „Development Tools“ mit zu installieren.

########################################
##   CentOS 5.5 Web-Server Tuning     ##
##       http://www.bestblog.de       ##
########################################

##      EACCELERATOR Installation     ##

su - 

cd /tmp

wget http://bart.eaccelerator.net/source/0.9.5.2/eaccelerator-0.9.5.2.tar.bz2

tar -xjf eaccelerator-0.9.5.2.tar.bz2

cd eaccelerator-0.9.5.2

phpize

./configure

make

make install

Damit ist eaccelerator auf eurem Server installiert, aber noch nicht aktiv. Dazu muss in den passenden Pfad eine Konfigurations-Datei hinterlegt werden, die Ihr mit einem Texteditor der Wahl erstellen könnt. Ich beschreibe den Vorgang wie immer in VI / VIM.

Den Inhalt dieser Datei bitte aus dem unteren Kasten kopieren.

########################################
##   CentOS 5.5 Web-Server Tuning     ##
##       http://www.bestblog.de       ##
########################################

##     EACCELERATOR Konfiguration     ##
###          Erstellung              ###

su -

vi /etc/php.d/eaccelerator.ini

##     EACCELERATOR Konfiguration     ##
###          Befüllen                ###

extension="eaccelerator.so"
eaccelerator.shm_size="0"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

##     EACCELERATOR Konfiguration     ##
###    Cache-Verzeichnis Erstellen   ###

mkdir -p /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

#####################################
##     WebServer neu starten       ##
#####################################

su -

/etc/init.d/httpd restart

Der eaccelerator ist nun installiert und aktiviert. Ruft euren Blog auf und bewundert, wie schnell sich die Seiten aufbauen. Ich habe damit eine Steigerung erreicht, die jederzeit den Eindruck vermittelt, die Seite würde aus dem LAN aufgerufen. Allerdings ersetzen all diese Änderungen keine gute Anbindung an’s Internet.

Happy fast-as-hell browsing,

j.klein

WordPress: Frühjahrsputz MySQL Datenbank

Donnerstag, Februar 18th, 2010

Demnächst ist Frühling und da hat mich auch mal das „Putzfieber“ überkommen. Allerdings nicht mit Besen und Kehrblech, sondern mit eineigen MySQL Kommandos und nützlichen Plugins für meine Blog-Software.

WordPress Clean Up

Dazu habe ich folgende Seite genutzt und fast alle Tips einwandfrei anwenden können. Daher stammt übrigens auch das nette Bildchen zu dem Artikel. Deswegen auch der Quellen-Verweis. Bild: maketecheasier.com

Innerhalb der letzten Monate hat sich meine MySQL-Datenbank immerhin um ein paar MB vergrößert. Hauptsächlich ist dafür das „Revisioning“ verantwortlich. Damit ist gemeint, dass WordPress sich sämtliche Editions-Stati eines Artikels merkt und diese bereit hält, falls man auf eine frühere Version eines Artikels zurück möchte. Da alle Beiträge schon veröffentlicht sind und ich diese nur noch editiere, brauchte ich die ganzen Vorgänger-Versionen nicht mehr. Das machte die Datenbank gleich mal um 75% schlanker. Für die Säuberung nutzt man am besten Das Plugin Delete-Revision für WordPress.

Des Weiteren habe ich mich eines neuen Plugins bedient. Mit dem DB Optimizer kann mann auf seine Datenbanken eine Fülle von Optimierungs-Vorgängen loslassen, die zum Streamlining und zur Zugriffsoptimierung dienen. Auch das bringt mit Sicherheit noch ein paar Millisekunden schnellere Zugriffe.

Wo Plugins dazu kommen, müssen auch alte Plugins und deren Datenbank-Einträge gehen. Das ist bei WordPress mit dem Plugin Clean-Option sehr schön möglich. Hier kann man die Einträge auswählen, die von den alten und nicht mehr vorhandenen Plugins gemacht wurden und sich derer entledigen.

Alles in allem hat der „Frühjahrsputz“ in der Datenbank und den Files meines Blogs einiges an der Aufbauzeit verbessert und auch wieder Last von dem Server genommen. Der MySQL-Server läuft jetzt nicht mehr auf Hoch-Touren, wenn es eine Abfrage auf die Datenbank gibt und lässt den Apache nicht mehr warten.

Soweit ich das kontrolliert und gesehen habe, sind dabei keine alten Daten verloren gegangen und meine Beiträge sind auch noch alle da. Daher ist die Aktion ein voller Erfolg gewesen und wirklich zu empfehlen.

Warnung: Egal was man an seinem Blog ändert. Man sollte auf jeden Fall darauf achten, ein vollständiges Backup von der Datenbank und der File-Struktur zu haben, sonst kommt es zu bösen Überraschungen. Wer keine Ahnung hat, was er da tut, sollte generell die Hände von solchen Spielereien lassen, bis er sich eingänglich über die Thematik informiert hat.

Happy cleaning,

j.klein

Neue Basis (CentOS 5.2 – 64 Bit)

Samstag, Januar 2nd, 2010

Nachdem der Blog die letzten Tage ein paarmal kräftig gehustet hat und ich das etwas verkonfigurierte Debian-Squeeze, welches dem Web-Server zu Grunde lag nicht mehr retten konnte, war es nach einem Backup an der Zeit für eine neue Basis.

Der Hoster meines Servers bietet neben OpenSUSE und Debian auch die Installation von CentOS 5.2 in der 32 oder 64 Bit Variante an. Also war die Entscheidung recht schnell getroffen. So wirklich viel habe ich mit CentOS noch nicht gemacht, da es allerdings aus dem RedHat-Stamm entspringt, war das nicht wirklich ein Problem.

Zur Installation habe ich natürlich die minimale Variante genommen und nicht das vorkonfigurierte LAMP des Hosters. Nicht aus misstrauen, aber was man selber installiert kennt man einfach 😉

Die Installation geht in ca. 5 Minuten von statten.

Danach ist mit einigen Kommandos auf der CLI das System mit LAMP beglückt worden:

 su -
yum update
yum install httpd mysql mysql-server php php-gd php-mysql
/etc/init.d/httpd restart

Damit ist LAMP auf dem Server vorhanden und nach den üblichen Anpassungen in der Apache-Config und anlegen der MySQL-User ist auch meine Seite schnell wieder online gewesen.

Nun läuft BestBlog auf CentOS 5.2 in der 64 Bit Variante.

Performance-Vergleiche zu Debian kann ich erst in ca. 4 Wochen sinnvoll online stellen. Sollte euch bis dahin irgendwas ungewöhnliches auffallen, bitte einfach kurz per Mail schreiben.

Happy New Year,

j.klein

Widgets gefixed …

Donnerstag, Januar 22nd, 2009

Nach meiner Neu-Installation vom Server hatte ich ja ein paar Probleme mit meinen Widgets (Seiten-Boxen links und rechts von der Seite)…

Auf manchen Seiten hat alles wunderbar funktioniert und auf anderen wiederum hat man nur alles bis zum Kalender gesehen. Da bin ich erst mal relativ ratlos gewesen, da ich mich abgesehen von der Installation noch nie genauer mit WordPress beschäftigt hatte. 😛

Es war klar, dass Problem muss irgendwo mit einem der Widgets auf der rechten Seite vorliegen, weil der Rest einwandfrei funktioniert hat. Hier sei erwähnt, dass auch das Konfigurieren der Widgets über die Admin Oberfläche nicht mehr funktioniert hat 🙂 Da ich die Konfiguration der Widgets nicht in irgendeiner Konfigurations-Datei meiner WordPress Installation gefunden habe war auch recht schnell klar, dass ich wohl meine dürftigen MySQL Kenntnisse wieder ausgraben darf…

Also habe ich mich auf http://wordpress.org belesen, in welcher Tabelle die Konfiguration der Widgets vorgenommen wird. Wirklich gut dokumentiert auf der Seite, dass will ich an dieser Stelle mal festhalten 🙂

Ich habe dann auf jeden Fall über Umwege, wie zum Beispiel die Benutzung manch andere Themes rausgefunden, dass der RSS Feed von wetter.com Probleme machte…

Wen es auch mal treffen sollte:

  • Auf die Datenbank von WordPress zugreifen
  • Die Tabelle ist wp_options
  • Widgets sind mit widget_ eingefügt
  • widget_rss Heisst logischerweise das RSS Widget
  • widget_rss Löschen

Kaum hatte ich das verflixte Ding aus meiner Datebank gekickt, schon hat auch der Rest wieder einwandfrei funktioniert 🙂

Happy Widgeting,

j.klein