wenn es noch aktuell ist – die kiste sollte das locker wegstecken – plesk macht es mit der konfiguration manchmal etwas schwer.

suphp ist soweit ich weiß nicht mit fastcgi zu machen. fastcgi macht einen riesen unterschied. suphp selbst braucht man auch nicht. allerdings ist es mit plesk bis 8.6 soweit ich weiß nicht möglich php per default als fastcgi laufen zu lassen.

also umbedingt checken ob php wirklich per fastcgi läuft, weil suphp normalerweise für jeden request eine php instanz startet und das ist extrem langsam.

dann apache mpm_worker installieren das geht nur mit php wenn es als fastcgi läuft, unnötige apache module raushauen und entsprechend konfigurieren. hat den vorteil das alle statistischen files relativ fix rausgehauen werden da nur ein neuer thread erzeugt werden muss, was nur ein bruchteil der funktionalität benötigt. falls noch mod_php herumschwirrt ebenfalls raushauen, das macht fastcgi.

anderes problem könnte sein, dass ständig php prozesse erzeugt werden. da muss man ein wenig schauen wie es so durchschnittlich aussieht und dann entsprechend gleich beim server start die php binaries starten.

für mysql kann ich nur http://mysqltuner.com empfehlen. vorallem query_cache und thread_cache bringen wohl ne menge. bei den speicher angaben sollte man sich aber nicht umbedingt daran halten. eher weniger.

ansonsten ist der apc cache ganz brauchbar. der frisst nur einmal speicher und teilt den für alle php-fastcgi prozesse.

falls das nicht fruchtet eventuell mal ngix anschauen http://nginx.net/ – und per mod_proxy anfragen darüber laufen lassen für vbulletin und so sollte es auch rewrite regeln geben. ansonsten ist der tipp mit squid ganz brauchbar – der kann auch auf dem selben rechner laufen – squid braucht allerdings ram.

zu plesk – wenn es nur von dir genutzt wird kannst du es auch auf 1 prozess beschränken oder die oberfläche stoppen und halt bei bedarf starten.

vbulletin kann auch cachen – da weiß das forum bestimmt mehr.

ansonsten ein aktuelles php5 wirkt auch wunder (http://sebastian-bergmann.de/archives/634-PHP-GCC-ICC-Benchmark.html)

ich hab testweise den benchmark mal mit der beta von php 5.3 laufen lassen und die geschwindigkeit hat sich verdoppelt – wäre eventuell auch eine variante

kann man gefahrlos mit ngix und php 5.3 auf einem anderen port testen.

die kiste sollte das locker wegstecken

:-)

Ich schau gerne mal “in den Server rein” wenn du mir Zugriff gibst. Ein eigener Account mit vollen “sudo” Rechten wäre gut :-)

Einige Ideen die mir gerade so durch den Kopf gehen :

- einen kleinen zweiten Server mieten und squid als reverse proxy für deine “hungrigsten” Websites einrichten. Der “application Server” (Apache) kriegt somit sehr deutlich weniger Arbeit mit statischem Content (Bilder etc). Eine minimal Maschine mit Debian, 512MB RAM und 80GB Disk reichen da völlig, mit der kleinsten CPU die du kriegen kannst. Squid ist sehr optimiert :) [für einen temporären Test stelle ich gerne eine Maschine zur Verfügung]

- oder aber Squid auf die gleiche Maschine setzen, was allerdings wesentlich mehr Umkonfigurieren heisst, also Risiko und downtime.

- Phase 2 : PHP code so optimieren dass der zutreffende Output auch vom squid gecached werden kann : ETag caching, etc.

- mit dem Zend Profiler deinen Code mal durchlaufen lassen und die Ressource-fressenden Teile optimieren

- SQL query caching (mit Cache_Lite oder ähnlich) einrichten um MySQL zu schonen. Da dein Problem aber nicht MySQL zu sein scheint, bringt dies so direkt wahrscheinlich nicht viel.

- für Apache die MaxClients, MinSpareServers, MaxSpareServers etc anpassen

- idem : KeepAlive timeout runtersetzen (2-3 Sekunden sollten reichen, mit ‘nem Squid davor kannste sogar komplett ausschalten)

- eAccelerator Konfiguration tunen (Speicher etc.)

Noch ein Tip zur Sicherheit: die PHP Extension SUHOSIN leistet da Gutes!

PHP läuft auch bereits als mod_fcgi. Ausserdem ist suPHP installiert, so dass PHP unter der UID der jeweiligen Domain ausgeführt wird.

Ich würde dir ganz dringend empfehlen, mod_fcgid einzurichten und jede Domain unter einer eigenen UID ausführen zu lassen. Das verbraucht zwar mehr RAM pro Domain, es wird ja mind. immer ein PHP-Prozess gestartet, hat jedoch wesentliche Vorteile (Sicherheit, Analyse, etc.)

top - 20:42:15 up 12 days, 9:10, 1 user, load average: 6.46, 6.88, 6.32
Tasks: 187 total, 5 running, 181 sleeping, 0 stopped, 1 zombie
Cpu(s): 79.5%us, 13.9%sy, 0.0%ni, 6.3%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2060396k total, 1728952k used, 331444k free, 70552k buffers
Swap: 2097140k total, 5560k used, 2091580k free, 1163916k cached

@Johny: Laut Hetzner ist das RAM Upgrade Hardwareseitig auf 2 GB limitiert. Beim Server müsste es das alte Modell mit DDR400 RAM sein.

Es handelt sich zudem um ein Hardware RAID. Kann mal als Option dazu bestellen.

Ist Raid ein Soft-Raid oder Hard-raid? und vor allem verlangsamt Raid 1 den Zugriff ja eigentlich auch :/

Ohne mehr zu wissen: MySQL-Anfragen analysieren und dort noch etwas optimieren, die Karre swappt ja noch nciht…

Ich habe keine Videos oder sonstige grössere Dateien auf dem Server, deshalb hält sicher der Traffic in Grenzen. Bei Hetzner ist allerdings “nur” 1 TB inklusive, danach wird die Anbindung auf 10 Mbit/s herunter gedrosselt. Also bin ich froh, dass der Traffic so gering ist :)