Was empfehlen Sie zum Einrichten eines Shared Servers mit php [closed]

Persönlich, während Lighttpd OK ist, würde ich mit Nginx + FastCGI gehen, wenn Sie am Ende mit einer leichten Webserver + FastCGI Lösung gehen. Ich habe Benchmarks ausgeführt und den ganzen Code gelesen, und Nginx ist eine Größenordnung schneller / stabiler unter Last - es ist sehr gut.

Aber das haben Sie nicht gefragt. Im Wesentlichen würde ich sagen, dass es in den drei Optionen, die Sie auflisten, ein Spektrum von Sicherheits- / Skalierbarkeits- und Geschwindigkeitsabwägungen gibt, und Sie müssen nur entscheiden, wo Sie sein möchten. Wenn Sie ein Shared-Hosting-Anbieter mit nicht vertrauenswürdigen Benutzern sind, die gottverdächtige PHP-Apps installieren, werden Sie mehr auf Sicherheit ausgerichtet sein. Wenn Sie dies unter vertrauenswürdigeren Benutzern teilen, können Sie sich der Leistung widmen. Hier sind meine Gedanken:

CGI + suexec: Dies ist bei weitem die sicherste und effizienteste / skalierbarste Lösung für Sie in Bezug auf die Anzahl der Nutzer / Websites in einer gemeinsam genutzten Hosting-Umgebung. Prozesse werden erzeugt, und Speicher wird nur verwendet, wenn Anfragen eingehen. Natürlich macht das CGI-Laichen dies am langsamsten für die Ausführungszeit einzelner Skripte. Wie viel langsamer? Nun, Sie müssten Benchmarks durchführen, aber generell, wenn Leute lang laufende Apps laufen lassen (dh so etwas wie WordPress, das 0,25-0,5 Sekunden benötigt, nur um seine Bibliotheken zu laden und bei jeder Anfrage zu initialisieren), dann fängt die CGI-Launch-Strafe an hübsch auszusehen im Kontext vernachlässigbar.

FastCGI: Das Problem hier (und es spielt keine Rolle, ob Ihr Webserver Apache, Lighttpd oder Nginx ist) ermittelt, wie viele FCGI-Kindprozesse Sie laufen lassen, weil jeder Prozess läuft isst Speicher gleich der Größe des PHP-Interpreters (in Linux ist natürlich nicht alles verdrahtet, aber ich schweife ab). Im Gegensatz zu mod_php werden diese Prozesse nicht von Benutzern verwendet, sodass Sie pro Benutzer einschränken müssen. Zum Beispiel, Dreamhost caps dies bei 3 für ihre Kunden - jetzt, für einen Kunden, der eine Website betreibt, die Ausbrüche von mehr als 2-5 Seitenaufrufe pro Sekunde bekommt, ist das eigentlich ziemlich schlecht, weil diese Anfragen nur stacken und die Seite hängt. Jetzt mag ich FastCGI mit einem leichten Webserver, wenn ich Apps auf einem dedizierten Server / Cluster betreibe, wenn ich der App hunderte von FCGI-Kindern geben kann (natürlich alle mit Webserver-Rechten à la Apache) / prefork + mod_php). Aber, ich denke nicht, dass es für Shared Hosting sinnvoll ist, wo Sie die FCGI-Kinder pro Benutzer zuweisen / begrenzen müssen.

Apache + mod_php: Mindestens sicher, da alles, was mit Webserver-Rechten läuft, aber Ihr Pool von Live-PHP-Prozessen geteilt wird, so dass es am besten auf der Leistungsseite ist. Aus der Perspektive eines Entwicklers kann ich den php_safe-Modus nicht tolerieren, und aus Sicht eines Systemadmins ist es wirklich nur eine Illusion von Sicherheit (es dämmt gegen dumme Benutzer, schützt aber nicht vor einem tatsächlichen Angriff), also hätte ich lieber CGI, wenn mein Andere Option muss safe_mode enthalten.

Dreamhost macht eine Art Hybrid, sie tun standardmäßig Apache CGI + suexec, aber lassen Sie den (kleinen) Prozentsatz ihrer mehr Benutzer, die anspruchsvoll sind, FCGI tun, wenn sie wollen, abhängig von einer Obergrenze und ihrer eigenen Überwachung der Speicherbelegung. Das spart eine Menge an Speicherressourcen im Gegensatz zur Aktivierung von FCGI für alle standardmäßig.

Ein weiteres Problem, wenn Sie über kommerzielles Standardhosting sprechen, ist, Apache ist voll ausgestattet, hat Module für fast alles (einschließlich Sachen wie mod_security, die Sie vielleicht wollen), und Ihre Benutzer werden es mögen, weil alle ihre .htaccess Configs funktionieren usw. - Sie werden Support-Probleme mit allem anderen bekommen, wenn sie Drupal oder WordPress oder was auch immer installieren (viel weniger ein Problem, wenn wir interne Benutzer sprechen).

Persönlich würde ich empfehlen, es einfach zu halten und mit CGI + suexec für beste Sicherheit und Skalierbarkeit zu beginnen und zu gehen. Wenn Ihre Benutzer FCGI oder mod_php wollen und Sie einen guten Kanal für Vorschläge / Kommunikation mit ihnen haben, werden sie danach fragen, aber beides ist ein viel größeres Kopfzerbrechen für Sie mit nur marginalen Leistungsverbesserungen für sie, so mein Vorschlag wäre es, wenn sie beide anfänglich nicht tun würden, aber reaktionsfähig sind, wenn sie danach verlangen.

Ich sympathisiere mit dem Wunsch, etwas "Interessantes" wie Lighttpd + FCGI anstelle des Standard-Apache + CGI + suexec zu tun, aber ich kann es im Grunde nicht empfehlen.

Wenn Sie mehrere Server betreiben, können Sie CGI auf etwas anderes und etwas anderes auf die anderen Benutzer aufsetzen. Und sicher sein, cron grep alle www dirs für Dinge wie alt-ass Versionen von phpBB!

In Bezug auf PHP + FastCGI und Sicherheit, überprüfen Sie dieser Blogbeitrag .

  

Die Herausforderung mit der Sicherung eines Shared   hosting server ist wie man das sichert   Website von Angriff sowohl von der   von außen und von innen. PHP hat   integrierte Funktionen zu helfen, aber   Letztendlich ist es der falsche Ort   adressiere das Problem.

     

Ich habe bereits über eine Reihe von geschrieben   Lösungen, die funktionieren, aber eine Option   Ich wurde immer wieder gefragt   Betrachten Sie mit PHP + FastCGI. Das   Glaube ist, dass FastCGI wird   Überwinde die Leistungsprobleme von   Apache suexec oder mod_suphp, weil   FastCGI-Prozesse bleiben zwischen den Seiten bestehen   Ansichten.

     

Aber bevor wir Leistung betrachten können,   Die erste Frage lautet: Wie genau?   Wir bekommen PHP und FastCGI läuft als   verschiedene Benutzer auf dem einen Webserver   an erster Stelle?

Ich habe InterWorx seit ungefähr einem Jahr benutzt und bin sehr beeindruckt. Es verwaltet einen LAMP-Server mit Chroots Ihre Skripte für die Sicherheit.

Ich habe auch Ensim verwendet, aber ich fand es nicht so freundlich, schnell und es hat nicht so viele Funktionen. Plus es kostet viel mehr.