gerade die letzten wochen habe ich mich ziemlich mit performance von webseiten
und servern sowie der maximalen auslastung der hardware bei einem optimalem
ergebniss beschäftigt ... zugegeben ich hatte ein dankbares
versuchtsobjekt bei dem es auf ein optimum an
leistung geht. grundsätzlich sollte das objekt aus der shared hosting lösung
auf einen eigenen server gebracht werden. erstmal so vom grundsatz her nicht
schwer und es wäre grundsätzlich innerhalb weniger stunden fertig gewesen.
aber um einmal zu zitieren unser server bekommt also rally-streifen, wird
tiefer gelegt und die maschine erhält ein chiptuning so ähnlich drückte es
das team aus, als ich ihnen mitteilte was gemacht wird an dem server. erstmal
die hardware, es handelt sich um eine dell 1850 mit einer (xeon) cpu mit 2 GB
ram und scsi festplatten. von der belastung der shared hosting lösung auf dem
das objekt bisher lag und dieser ausstattung war mir klar das hiermit maximal
10 000 pi/hhiermit sind Page Impression pro Stunde gemeint (Unique), also wie
häufig in einer Stunde auf die seite zugegriffen wurde möglich sind. da ein
entsprechendes budget für bessere hardware nicht unbedingt vorhanden ist und
mein ergeiz auch noch angespornt wurde habe ich mich mit optimierung
beschäftigt. die wahl des betriebssystems viel auf ubuntu-server (6.06),
eigentlich aus genau zwei gründen - die von mir gewünschte software ist
bereits als paket vorhanden, die software ist aktuell gehalten. aber ein
weiterer wichtige punkt war für mich,die guten erfahrungen die ich bisher mit
ubuntu an sich und der server-version um speziellen gemacht habe. als mailer
setze ich auf exim, der ist einfach schnell und durch
die arbeit bedingt ist mir die konfiguration auch nicht fremd und es geht
leicht von der handaber natürlich verwende ich den alten weg über eine datei
und nicht die ganzen verzeichnisse ... das ganze ist als virtuelles mailsystem
ausgelegt, damit die benutzer nicht im system existieren müssen. für den ftp
zugriff ist pure-ftpd eingesetzt, weil es mir
dieser erlaubt mehrere virtuelle benutzer auf einen realen benutzer zu mappen.
das ganze damit es keinerlei probleme mit rechten oder besitzern gibt. für die
schnelle datenbank sorgt ein mysql 5 server mit ausreichendem quere-cache,
ausgeschaltetem bin log und ein wenig mehr tuning. die eigentlich webseite
wird über einen lighttpd mit
php5-cgivia fast-cgi
ausgeliefert. da die load bei einem durchschnittlichen tag (bis maximal 5000
pi/h) für mein empfinden zu hoch war (peaks bis 9 waren drin), habe ich dann
nach etwas ausprobieren mit dem
ZendOptimizerhat nicht
wirklich etwas beim speed gebracht und da keine kompilierten binarys benutzt
werden, ist er gleich wieder vom system runter gekommen mich dazu entschieden
apcalternative php cache zu installieren.
danach ist die load um mehr als 2 drittel gesunken. was zur folge hat, das der
server an einem tag mit spitzenzugriffen (ca. 6000 pi/h) gerade mal mit einer
load von 1 nicht gerade sehr ausgelastet war. so muss es sein, gerade in
anbetracht dessen das jetzt vorerst die hardware reichen muss / sollte. das
schöne ist, jetzt ist noch viel luft vorhanden und der server ist vorerst
ausreichend selbst wenn sich die zugriffszahlen verdoppeln sollten. was auch
wieder einen performance gewinn gebracht hatte, war die umstellung auf den
feedburner. jedoch mit einem kleinen trick. das normale wordpress feedburner
plugin bedient sich der .htaccess datei und erweitert diese, sodas es mit
einem rewrite möglich ist die zugriffe umzuleiten. das versuchsobjekt hat aber
nur die normale directlink struktur und somit erfolgt der zugriff auf die
feeds über die wp-(rss|rss2|atom).php dateien. der für mich eleganteste weg
war jetzt dem server gleich zu sagen das er die anfragen an diese dateien zu
feedburner umleiten soll. der lighttpd bietet hier eine einfache
konfigurationsmöglichkeit $HTTP["useragent"] !~ "FeedBurner" { url.redirect = ( "^/wp-(rss2|rss|atom).php" => "http://feeds.feedburner.com/Bildblog" ) }
also ziemlich simpel. von der server software ist das ganze jetzt auf leistung
getuned, das wordpress kann noch etwas mit [wp-cache](http://mnm.uib.es/gallir
/wp-cache-2/) getuned werden, aber vorerst sollte das nicht nötig sein ...
schauen wir mal wieviele pi's das system aushält.
{% include JB/setup %}