Suphp Fehler nach php downgrade

#1
Hallo,
Ich habe von php 5.4.x auf php 5.5.x geupgradet, musste danach jedoch php - Fehler auf der Seite feststellen und habe daraufhin wieder auf php 5.4.x gedowngradet.

Jetzt funktioniert suphp nicht mehr, da der php Code ausgeben und nicht mehr interpretiert wird.

Auf dem Server läuft Debian 7 mit ispconfig.

Hat jemand einen Tipp?

Danke.
 
#2
Wie hast Du denn den Downgrade vollzogen? Bzw wie den upgrade?
Was steht zu dem Fehler im Log?

Kleine Anmerkung, suPHP ist grottenlahm, da gibts schickere Alternativen, das aber nur anbei.

Gruß Sven
 

nowayback

Well-Known Member
#3
für mich klingt es als wäre in der seite php nicht erlaubt aber sven hat recht, logs checken, und wenn es keinen speziellen grund für suphp gibt, auf fastcgi wechseln.
 
#4
Vielen Dank für die schnellen Antworten. :) Ich hatte das Apache su_php Modul nicht aktiviert. a2enmod su_php ...
@FARR3[SIZE=4]LL[/SIZE] Im Prinzip bin schon an schnelleren Lösungen interessiert. @nowayback Du hast fastcgi anklingen lassen. Was wäre Eures Erachtens die performanteste Lösung?
Danke und Grüße,
Sven
 

nowayback

Well-Known Member
#5
#6
Vielen Dank, ich habe Fast-CGI + suExec soeben gestestet und es bringt in der Tat, eine bessere Performance.

Was haltet Ihr von mod_pagespeed, APC oder XCache usw. und welche Kombination würdet Ihr empfehlen?

Sven
 

nowayback

Well-Known Member
#7
Vielen Dank, ich habe Fast-CGI + suExec soeben gestestet und es bringt in der Tat, eine bessere Performance.

Was haltet Ihr von mod_pagespeed, APC oder XCache usw. und welche Kombination würdet Ihr empfehlen?

Sven
mod_pagespeed ist auf jeden Fall sinnvoll. APC oder XCache ist reine Geschmackssache. Von der Performance nehmen die sich eigentlich nichts. Für Datenbankabfragen macht memcached evtl. noch ordentlich was aus und wenn du es wirklich auf Speed abgesehen hast, dann hilft ein Umstieg auf nginx + mariadb/percona + gzip + apc/xcache + memcache + Varnish + RamFS/tmpFS (+ ngx_pagespeed (kann die Geschwindigkeit in dem Setup negativ beeinflussen, keine Ahnung warum. Habs noch nicht rausgefunden)).
 
#8
Super fundierte Auskünfte :) Ich würde schon gern den Apache behalten. Also wäre für diesem Fall beispielsweise eine sinnvolle Konfiguration Fast-CGI + suExec + mod_pagespeed + apc + memcache?

Danke und Grüße, Sven
 

Till

Administrator
#9
Ja, das wäre eine ordentliche Konfiguration. Du kannst statt fastcgi auch php-fpm nehmen. Das ist eine etwas modernere Variante der PHP Anbindung mit den selben Vorteile wie fastcgi. Wahrscheinlich wirst Du aber nur bei hoher last Unterschiede merken.
 
#11
Ich nutze seit geraumer Zeit auch php-fpm. Hab damit auf nginx angefangen und das dann auch auf den Apache Servern eingesetzt. Ich bin damit selbst ohne Tuning sehr zufrieden.
Bzgl apc xcache memcache und co, das kommt schlicht auf den Aufbau der Webseite an ob und was man hiermit erreicht.


Grüßla Sven
 

nowayback

Well-Known Member
#12
ich setzt bei apache immernoch auf fastcgi+suexec, aber klar bei nginx kommt php-fpm zum einsatz. Ich teste im Moment auch viel rum, z.B. mit nginx 1.6.2 + ngx_pagespeed + memcached/varnish und den ganzen Krempel...
Bei niedriger Auslastung bringt nur ngx_pagespeed einen Performancegewinn - mit einer Ausnahme: Die Zeit bis das erste Byte übertragen wird, ist mit Varnish und Memcached deutlich niedriger als ohne.

Hier mal ein paar Vergleichswerte:

Nginx 1.2.1 without any caching
Code:
                       Load Time   First Byte  Start Render  Speed Index    
First View (Run 1)     1.597s      0.260s      1.192s        1230
Repeat View (Run 2)    0.792s      0.290s      0.793s        800
Nginx 1.6.2 ngx_pagespeed + memcached + varnish
Code:
                       Load Time  First Byte  Start Render  Speed Index
First View (Run 9)     1.380s     0.037s      0.486s        510 
Repeat View (Run 5)    0.460s     0.043s      0.390s        405
Ich zitiere mal Pingdom:
Your website is faster than 92% of all tested websites
Mal sehen ob sich das wirklich produktiv nutzen lässt... Achja, ISPConfig ist natürlich installiert und wird auch genutzt. Als Datenbank ist beim Nginx 1.6.2 aktuell MariaDB im Einsatz. Leider war der Performancegewinn durch die Datenbankumstellung von MySQL zu MariaDB deutlich kleiner als erwartet und kann daher vernachlässigt werden.
 
Zustimmungen: Till

nowayback

Well-Known Member
#13
Ich will den Thread eigentlich nicht hijacken, aber es passt eben noch dazu...

hier mal noch die Werte von ApacheBench:
Nginx 1.2.1 without any caching
Code:
Concurrency Level:      100
Time taken for tests:   47.389 seconds
Complete requests:      1000
Failed requests:        944
   (Connect: 0, Receive: 0, Length: 944, Exceptions: 0)
Write errors:           0
Total transferred:      46384056 bytes
HTML transferred:       46069056 bytes
Requests per second:    21.10 [#/sec] (mean)
Time per request:       4738.865 [ms] (mean)
Time per request:       47.389 [ms] (mean, across all concurrent requests)
Transfer rate:          955.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   22  51.8      4     189
Processing:   593 4554 1229.3   4378    8189
Waiting:      562 4534 1224.0   4361    8135
Total:        756 4577 1205.7   4389    8194
Nginx 1.6.2 + ngx_pagespeed + memcached + varnish
Code:
Concurrency Level:      100
Time taken for tests:   6.537 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      49329953 bytes
HTML transferred:       49012000 bytes
Requests per second:    152.98 [#/sec] (mean)
Time per request:       653.691 [ms] (mean)
Time per request:       6.537 [ms] (mean, across all concurrent requests)
Transfer rate:          7369.51 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   6.5      0      25
Processing:    31  622 113.8    669     726
Waiting:       19  622 113.9    669     725
Total:         38  625 108.9    669     726
Ich konnte Nginx 1.6.2 + ngx_pagespeed + memcached + varnish nochmal optimieren...
Code:
Concurrency Level:      100
Time taken for tests:   3.143 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      49330028 bytes
HTML transferred:       49012000 bytes
Requests per second:    318.21 [#/sec] (mean)
Time per request:       314.262 [ms] (mean)
Time per request:       3.143 [ms] (mean, across all concurrent requests)
Transfer rate:          15329.19 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   2.8      0      15
Processing:    21  303  93.9    326     493
Waiting:        9  228  76.9    258     393
Total:         23  304  94.7    326     502
und weil es mich mal interessiert hat auch noch mit Nginx 1.6.2 + ngx_pagespeed + hhvm
Code:
Concurrency Level:      100
Time taken for tests:   22.393 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      51973000 bytes
HTML transferred:       51536000 bytes
Requests per second:    44.66 [#/sec] (mean)
Time per request:       2239.332 [ms] (mean)
Time per request:       22.393 [ms] (mean, across all concurrent requests)
Transfer rate:          2266.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.4      0       6
Processing:   203 2133 360.1   2226    2382
Waiting:      202 2132 360.1   2225    2381
Total:        209 2133 358.9   2226    2382
Erstaunlich, ist, das HHVM deutlich langsamer ist, als die Varnish Variante. Ich hätte da auch mit anderen Ergebnissen gerechnet.
 
Zuletzt bearbeitet:
Zustimmungen: Till

Till

Administrator
#14
Sehr interessant, hätte nicht gedacht dass man mit varnish vor nginx noch so viel erreichen kann. Welche Software lief auf dem Webspace den Du getestet hast, ein cms wie wordpress? Varnish kann ja nur die Auslieferung statischer Dateien beschleunigen, daher würde ich mal vermuten dass man varnish und hhvm nicht direkt vergleichen kann. Man müsste wohl php-fpm gegen hhvm bei sonst unverändertem Setup vergleichen wenn man sehen möchte was hhvm bringt.

Wie hast Du den memcached eingesetzt? Als schnellen cache für pagespeed?

Hast Du RAM Drives eingesetzt? Beim aktuellen howtoforge.com Server setzen wir nginx als caching proxy for apache ein, wobei nginx die Dateien auf einem ramdrive cached und die Cachingverzeichnisse von Drupal liegen auch auf RAM Drives. Ist aber ein älteres setup, wenn die .com Seite als nächstes überarbeitet wird dann werde ich da auch was neues suchen.
 

nowayback

Well-Known Member
#15
Hi,

getestet hab ich es mit einer kleinen Wordpress Seite, die schon etwa ein Jahr produktiv läuft. Diese hab ich einfach geclont und auf die Testserver gespielt. Als Caching Plugin für Wordpress lief Cachify von Sergej Müller und als Caching Verfahren habe ich memcached eingesetzt. Das hab ich deshalb getan, weil memcached sich besonders auf Datenbankabfragen auswirken soll. Gleichzeitig landen auch die Files im Ram. Die fertig gerenderten Daten werden von Varnish gecached und ausgeliefert.

Um es mal bildlicher darzustellen:
Aufbau: Http(s) Request -> Varnish (Wenn Daten im Cache, dann direkt Antwort, wenn nicht dann: ) -> Nginx -> ngx_pagespeed -> Memcached -> Varnish -> Http(s) Antwort

Memcached selbst schreibt die Daten ja in den Ram. Nginx läuft ganz normal mit Daten von der Platte ohne RamFS. Das war auch meine Ausgangssituation. Mir ist klar, dass sich das ganze mit SSD's noch ändern könnte, sodass memcached da evtl. überflüssig wird, aber ich kann ja schlecht Äpfel miit Birnen vergleichen. ngx_pagespeed läuft auch einfach von der Platte, auch wenn mir bewusst ist, dass tmpFS die Sache weiter beschleunigen könnte. TmpFS hat für mich auf einer SSD jedoch den großen Nachteil der vielen vielen Schreibvorgänge bei den vielen kleinen Dateien die ein Webserver meistens ausliefert. Das bringt meiner Meinung nach die SSD viel zu schnell an ihr Lebensende. Deshalb setze ich das so nicht ein. Aber hier soll das jeder nach seinen Bedürfnissen und Mitteln entscheiden.
Varnish bietet auch noch den großen Vorteil, dass es eine definierte Dauer lang (z.B. 2 Stunden), auch Daten ausliefern kann, obwohl Nginx z.b. gerade nicht erreichbar ist. Die Caching Dauer lässt sich auch aufteilen, sodass man sagt, solange Nginx erreichbar ist, Cache 1 Minute, bei Nichterreichbarkeit 1 Stunde. Meiner Meinung nach müsste sich dadurch sogar eine einfachere HA Lösung umsetzen lassen, da man sich die Replikation der DB theoretisch sparen kann. Man müsste also nur den Varnish-Cache Server und was davor noch kommt, z.b. load balancer, hochverfügbar machen.

Man müsste wohl php-fpm gegen hhvm bei sonst unverändertem Setup vergleichen wenn man sehen möchte was hhvm bringt
Ich hab hhvm nur in Verbindung mit ngx_pagespeed getestet. Nginx 1.2.1 läuft mit php-fpm. Da haben wir etwa ne Steigerung von 100% zugunsten hhvm. Wenn man nun allerdings sieht dass das Varnish Setup etwa 7x schneller ist als hhvm, steht hhvm eigentlich schon nicht mehr zur Diskussion.

Ich werde die Tage nochmals alle Setups neu aufbauen und erneut testen um Fehler ausschließen zu können, aber es sieht ganz stark danach aus, als wenn ich demnächst schauen muss, wie ich varnish in ispconfig integrieren kann, aber das dürfte ja gar nicht so schwer sein ;-)
 

nowayback

Well-Known Member
#16
es sieht ganz stark danach aus, als wenn ich demnächst schauen muss, wie ich varnish in ispconfig integrieren kann, aber das dürfte ja gar nicht so schwer sein
tja... so einfach ist es doch nicht, da alles in eine Datei geschrieben werden muss, bzw. alle webs aus der DB ausgelesen werden müssen um die Daten zu schreiben und das geht doch gewaltig auf die Performance, weil Varnish kein include *.vcl unterstützt sodass man es auf je ein web unterteilen kann :-/

aktuell haben wir ein view im einsatz mit allen ips und domains, aber auch da ist die performance bei unserer testdb (mit testeinträgen in einem praxisnahen Scenario) nicht wirklich viel schneller... hier müssen wir uns wohl noch was einfallen lassen.
 
Zuletzt bearbeitet:

Werbung