Response zu lange

[ephigenie]

Ok

1) Dein Flaschenhals ist zuallerersteinmal deine MySQL
2) ~350kbyte / s sind jetzt nicht ungewöhnlich

Shopsystem bei mir DB - Bound (schaut ähnlich aus) :

Quote:Document Path: /index.php
Document Length: 103455 bytes

Concurrency Level: 1
Time taken for tests: 211.200733 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 103806000 bytes
HTML transferred: 103455000 bytes
Requests per second: 4.73 [#/sec] (mean)
Time per request: 211.201 [ms] (mean)
Time per request: 211.201 [ms] (mean, across all concurrent requests)
Transfer rate: 479.98 [Kbytes/sec] received

Joomla nicht ganz so db bound (aber ohne caching) :

Quote:Document Path: /index.php
Document Length: 12806 bytes

Concurrency Level: 10
Time taken for tests: 159.622590 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 13291000 bytes
HTML transferred: 12806000 bytes
Requests per second: 6.26 [#/sec] (mean)
Time per request: 1596.226 [ms] (mean)
Time per request: 159.623 [ms] (mean, across all concurrent requests)
Transfer rate: 81.31 [Kbytes/sec] received

Da schau mal einer an ... fast 40% schneller (gemessen an req/s)

Zum Vergleich dieses Forum mit lighttpd + php5-cgi (+eA)

Quote:Document Path: /forum/index.php
Document Length: 41579 bytes

Concurrency Level: 10
Time taken for tests: 117.942568 seconds
Complete requests: 1000
Failed requests: 204
(Connect: 0, Length: 204, Exceptions: 0)
Write errors: 0
Total transferred: 42073664 bytes
HTML transferred: 41576750 bytes
Requests per second: 8.48 [#/sec] (mean)
Time per request: 1179.426 [ms] (mean)
Time per request: 117.943 [ms] (mean, across all concurrent requests)
Transfer rate: 348.36 [Kbytes/sec] received

Die Werte sind nicht so unüblich.
Bitte mach einen Vergleichstest mit mod_php und beachte dabei die Serverload.

Bedenke bei deinem Test auch, dass in der Fastcgi Config -maxClassProcesses 10
Standard ist -> sprich >10 php requests unter einem User werden in die queue gestopft und erst nacheinander abgearbeitet. Vorteil an der Sache :
worker_mpm kann wunderbar mit so einer queue umgehen.
prefork_mpm kann es nicht - sondern würde für jede deiner Verbindungen einen Apache forken -> schau dann mal was deine anderen Domains zu machen

Ergo : brauchst du mehr konkurrent connections auf einer domain musst du im Fastcgi noch ein wenig rumspielen. Aber bei >10 konkurrenten php zugriffen komm ich wieder auf den Punkt zurück - das da i.d.R. erstmal deine DB versagen wird.
Und das deine Mysql unkonfiguriert ist, sehe ich direkt mal an ihrem Speicherverbrauch für 100 concurrent requests sollte da dann auch durchgehend auf performance getrimmt werden.
ispCP ist nicht die holy cow die dir alles und jedes abnimmt.
Aber lange Wartezeiten auf deine Db erzeugen requeststau beim php - damit mehr parallele prozesse (die alle auf die db warten) und damit mehr load ...

Zu guter letzt ist noch anzumerken - man sollte nat. nicht Äpfel mit Birnen vergleichen - unterschiedliche Applikationen = unterschiedlichen Anforderungen.

Der Punkt ist der - dass grade unter Hochlast am Ende ein ispCP mit fastcgi und apache mpm-worker und ordentlich konfigurierter DB deutlich stabiler läuft als ein prefork apache mit mod_php.
Hochlast = viele konkurrente unterschiedliche Zugriffe.
Pi * Daumen sagt man das fastcgi/php vs. mod_php etwa 90-95% der Leistung hat.
Aber dazu kommt halt noch - das mpm-worker deutlich schneller & Laststabiler bei der Auslieferung vieler statischer Dateien ist als prefork apache und zudem einen riesigen Unterschied in Bezug auf die Sicherheit deiner Hostingumgebung macht (www-data vs. vu20xx User)