nicht angemeldet
Re:
Kannst du mal ein bisschen über die Performance reden? Wies da aussieht?
Jede Servertechnik, die eine Erweiterung (Servermodule, CGI-Scripte, Datenbankanbindungen, etc.) der Funktionalität des Webserver bereitstellt, kostet. Diese Kosten sind zum einen mit der Hardware zutragen (CPU-Last, RAM, etc.), zum anderen mit der Geschwindigkeit, die zur Verarbeitung einer Anfrage benötigt wird. Dabei ist die Zeit meiner Erfahrung nach das kleinere Problem, was vielleicht auf den ersten Blick verdreht erscheint. Es ist tatsächlich nämlich nicht das Problem, ob eine Anfrage in 0,03 oder in 0,2 Sekunden bearbeitet wurde, da der Seitenbesucher nicht von der Servergeschwindigkeit abhängt. Er ist abhängig von der seines (DSL-)Anschlusses. Aller Wahrscheinlichkeit nach hat dieser, wenn er nicht google heißt, eine erheblich geringere Bandbreite als der Webserver. Vorderrangig ist also, ob der Server mit jeder Erweiterung durch größeren Verbrauch an Systemressourcen die Bandbreite mangels Leistung drosselt. Da ich Deine Hardware nicht kenne, gehe ich nur auf die Geschwindigkeit und die allgemeingültigen Konzepte ein. Es gibt etliche Ansätze, für Beschleunigung zu sorgen. Dazu lohnt es sich im einzelnen, _alle_ Komponenten, und was sie tun, zu betrachten. Schon mal vorweggenommen ist das Schielen _nur_ auf mod_rewrite garantiert der Falsche Weg. In Deinem Fall sind die Komponenten der Apache, mod_rewrite, PHP und das Webprojekt selbst:
Zum Apachen/Webserver:
Gerade beim Webserver finden sich die meisten möglichen Aspekte, Performance zu steigern, jedoch sind sie, in der Gesamtschau oftmals nachrangig. So kann man an seinem Server optimieren bis zum letzten gesparten Bit, was man mit einer CGI-Anwendung (CGI ist ein wirklich lahmes Interface) hintenrum wieder zunichte macht. Was kann man also alles machen? Zunächst einmal sich fragen, ob ich das richtige Produkt für mein Projekt habe. Apache ist nicht der schnellste Webserver. Das sollte man wissen. Beispielhaft sei hier nur auf lighttpd und nginx als Alternativen verwiesen.
Kompression ist ein weiterer Aspekt, wenn der Datendurchsatz bei sehr vielen parallelen Anfragen gesteigert werden soll. Hierbei gilt mod_negotation mit vorkomprimierte Dateien serviert schneller und ressourcenschondender als mod_deflate oder PHP (zlib -> Ausgabekompression) und on-the-fly-compression.
Dafür zu sorgen, dass Verbindungen ausreichend lange offen bleiben (Stichwort Keep-alive), kann für den Webnutzer sogar spürbar Geschwindigkeitsvorteile bringen. Hier kann ich aus eigener Erfahrung auch für den produktiven Einsatz mit Apache mod_event empfehlen.
Das Erlauben von Verzeichnisweiter Konfiguration (.htaccess) ist eine große Geschwindigkeitsbremse.
Andere Aspekte hat Christian Kruse in einem Artikel zusammengefasst.
Zu mod_rewrite:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php [L]
Das Modul ruft im ersten Fall (!-d) stat() auf, lässt also das System prüfen. Im zweiten Fall (!-f) wird wieder das System mit lstat() bemüht. In der Tat ist das nicht der performanteste Weg. Er ist aber überaus einfach und portabel. Wenn man die Verzeichnisstruktur seines Projektes genau kennt und sie sich nicht alle Nase lang ändert, ist es erheblich sinnvoller, auf die Verzeichnisnamen in einem Pattern zu testen, da, ohne es jetzt mit einem Benchmark belegen zu können, ein geringer Geschwindigkeitsvorteil zu erwarten sein sollte. Eine entsprechende Rewrite-Kondition könnte für Dich so aussehen:
`RewriteCond %{REQUEST_URI} !^/(Img|Scripts|Styles)`{:.language-apache}
Zu PHP:
Betrachtungen der Performance sind fast ausschließlich hier relevant. Daher schrieb ich auch, dass bei mod\_rewrite keine nennenswerten Effekte zu erwarten seien. PHP kommt in der Gesamtbetrachtung die Rolle des Schwarzen Peters zu. Jede angeforderte Ressource, die nicht durch erst PHP generiert werden muss, wird schnell und systemschonend serviert. Man kann das immer wieder erneute Analysieren des Scriptcodes durch code-caching beschleunigen. Hier sei nur beispielhaft auf [eAccelerator](http://eaccelerator.net/), [APC](http://www.php.net/package/apc) und einen [Benchmark](http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html) verwiesen.
Das PHP-Modul ist sehr viel schneller als PHP über CGI - und wenig schneller als PHP über FastCGI anzusprechen. Jedoch Vergrößert es auch die Arbeiterprozesse der Webserver erheblich, sodass eine Pauschale eigentlich nicht statthaft ist. In den überwiegenden Fällen wird man mit PHP als FastCGI-Applikation am besten fahren, obwohl es etwas langsamer ist. Die maximal verbrauchten Systemressourcen sind jedoch konfigurierbar und für Berechnungen relativ genau vorhersagbar.
Weiterhin sollte auch der Scriptcode optimiert werden. Das betrifft nicht so sehr Prozeduren und adäquate Code-Varianten als vielmehr strukturierte Programmierung an sich. Christian Seiler hatte das sehr gut [zusammengefasst](http://forum.de.selfhtml.org/archiv/2008/8/t175998/#m1157633), worauf es ankommen sollte. (Über die dortige Hetzjagt im Gesamtverlauf der Beiträge kann ich allerdings immer wieder nur den Kopf schütteln, was alles trotz Moderation in diesem Forum hier veranstaltet werden kann.)
Zum Webprojekt:
Generell werden statische Dokumente am schnellsten serviert. Wer also Geschwindigkeit, Bandbreite und Systemressourcen im Auge halten muss, macht sich von vornherein Gedanken, wie er sein Projekt strukturiert: Muss alles dynamisch generiert werden, was die Performance beeinträchtigt? Wie kann ich oben angesprochene Kompression vielleicht nutzen? Dazu will ich nur auf andere [Beiträge im Archiv](http://forum.de.selfhtml.org/archiv/2009/6/t188297/#m1253164) verweisen, die das Thema sehr ausführlich behandeln. Anzumerken bleibt, dass man das Servieren durch Auslagerung des Projektes in den Arbeitsspeicher (Stichwort ramfs) nochmals etwas beschleunigen kann. Dies betrifft prinzipiell auch Datenbanken.
Gruß aus Berlin!
eddi