Suphp Fehler nach php downgrade

Dieses Thema im Forum "Server Administration" wurde erstellt von webmystar, 21. Sep. 2014.

  1. webmystar

    webmystar New Member

    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. F4RR3LL

    F4RR3LL Member

    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
     
  3. nowayback

    nowayback Well-Known Member

    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. webmystar

    webmystar New Member

    Vielen Dank für die schnellen Antworten. :) Ich hatte das Apache su_php Modul nicht aktiviert. a2enmod su_php ...
    @FARR3LL 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
     
  5. nowayback

    nowayback Well-Known Member

    Ganz einfach: Fast-CGI + suExec
     
  6. webmystar

    webmystar New Member

    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
     
  7. nowayback

    nowayback Well-Known Member

    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. webmystar

    webmystar New Member

    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
     
  9. Till

    Till Administrator

    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.
     
  10. webmystar

    webmystar New Member

    Vielen Dank ich teste das die Tage aus und poste dann die Ergebnisse! ;-)
     
  11. F4RR3LL

    F4RR3LL Member

    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
     
  12. nowayback

    nowayback Well-Known Member

    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:
    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.
     
    Till gefällt das.
  13. nowayback

    nowayback Well-Known Member

    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: 23. Sep. 2014
    Till gefällt das.
  14. Till

    Till Administrator

    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.
     
  15. nowayback

    nowayback Well-Known Member

    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.

    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 ;-)
     
  16. nowayback

    nowayback Well-Known Member

    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: 28. Sep. 2014

Diese Seite empfehlen