macht .htaccess langsam?

[Donald]

Hallo,

Ich habe ein administratives Unterverzeichnis meines gehosteten Verzeichnisses (Apache) mit .htaccess geschützt. Nun wird mir gesagt, dass ich damit den Apache deutlich bremsen würde, da diese .htaccess-Datei jede Menge I/O auf dem Server produziert (muss ja dauernd gelesen werden).

Ist das so? Ist das merklich? Wie machen das grosse Seiten mit Mio Zugriffen am Tag?

Oder soll der Bereich ausgelagert werden um dann als Virtueller Host anderst behandelt zu werden?

Grüsse,

V. Schmid

[Klaus]

Hallo,

Ich habe ein administratives Unterverzeichnis meines gehosteten Verzeichnisses (Apache) mit .htaccess geschützt. Nun wird mir gesagt, dass ich damit den Apache deutlich bremsen würde, da diese .htaccess-Datei jede Menge I/O auf dem Server produziert (muss ja dauernd gelesen werden).

Ich weiß ja nicht wieviele Hits du am Tag auf dein administratives Verzeochnis hast, aber natürlich bedeutet .htaccess benötigt mehr Performance.
Da HTTP Verbindungslos ist, wird bei jedem Aufruf das PW mitübertragen, welches dann auch immer überprüft werden muss.
Allerdings sooo rechenintensiv ist es nicht, als das man sich darüber gedanken machen müsste.

Wie machen das grosse Seiten mit Mio Zugriffen am Tag?

Die nutzen nur sehr sehr selten .htaccess-Zugangsschutz (eigentlich nie), aber nicht auf grund der Perfomance sondern weil es nicht die Skalierbarkeit & Flexibilität bietet, die man benötigt.

MFG

[Cheatah]

Hi,

Wie machen das grosse Seiten mit Mio Zugriffen am Tag?
Die nutzen nur sehr sehr selten .htaccess-Zugangsschutz (eigentlich nie),

es geht bei der Problematik nicht um den Zugangsschutz, sondern um .htaccess.

aber nicht auf grund der Perfomance

Doch, definitiv auch wegen der Performance. Die Betrachtung verzeichnislokaler Konfigurationsdateien ist bei solchen Servern in aller Regel ausgeschaltet, d.h. eine vorhandene .htaccess-Datei würde nicht beachtet werden.

Cheatah

[Christian Seiler]

Hallo,

Ich habe ein administratives Unterverzeichnis meines gehosteten Verzeichnisses (Apache) mit .htaccess geschützt. Nun wird mir gesagt, dass ich damit den Apache deutlich bremsen würde, da diese .htaccess-Datei jede Menge I/O auf dem Server produziert (muss ja dauernd gelesen werden).

Die grundsätzliche Aussage, dass .htaccess langsamer ist, als direkte Serverkonfiguration, ist erst einmal richtig:

Wenn .htaccess aktiviert ist, muss in jedem Verzeichnis nachgesehen werden, ob's dort eine .htaccess gibt und die muss dann eingelesen werden. Dann muss der Inhalt verarbeitet werden und dann erst kann sich der Apache um das nächste Verzeichnis kümmern (bis man halt beim tiefsten Verzeichnis ist).

Das gibt 2 Stellen, an denen Zeit verbraten wird:

1. Nachsehen ob eine .htaccess überhaupt vorhanden ist.
 2. Eine vorhandene .htaccess verarbeiten.

Punkt 1 wirst Du aber alleine durch Deaktivieren der .htaccess-Funktionalität (AllowOverride None) nicht los, denn jedes Verzeichnis wird IMMER angesehen wegen Symlinks *AUSSER* FollowSymLinks ist als Option gesetzt, was aber aus Sicherheitsgründen nicht unbedingt zu empfehlen ist, außer man benötigt es wirklich (normalerweise reicht SymLinksIfOwnerMatch). Den Overhead wirst Du also in der Regel nicht los. Bleibt das Verarbeiten der .htaccess. Zum einen: Wenn die Seite häufig aufgerufen wird, werden die .htaccess-Dateien natürlich vom Betriebssystem automatisch im Speicher gehalten. Das heißt: Die Festplatte muss (wenn der Server genug RAM hat, was idR. aber der Fall ist) nicht zusätzlich arbeiten. Bleibt im Endeffekt das Parsen der .htaccess übrig, was Dich Performance kostet.

Die Frage ist nun: Wie viel macht das aus?

Wir bei SELFHTML verwenden an verschiedenen Stellen der Bequemlichkeit halber .htaccess-Dateien und nutzen da NICHT die zentrale Serverkonfiguration. Auch bei "de.selfhtml.org", der ca. 1,5 Mio Anfragen pro Tag erhält. Dennoch haben wir keinerlei Performanceprobleme auf Grund von .htaccess - man merkt das bei uns gar nicht.

Nach meiner Erfahrung als Administrator hier sind die wahren Performancekiller schlecht geschriebene Webapplikationen, sprich: Dynamische Inhalte. Ein bisschen .htaccess-Rumparsen vom Webserver ist irrelevant im Vergleich zur Zeit, die bei dynamisch generierten Inhalten draufgeht.

Daher, meine persönliche Erfahrung: Verwende guten Gewissens weiter .htaccess, bevor Dir der Webserver deswegen um die Ohren fliegt, ist er Dir 100x wegen dynamischen Inhalten um die Ohren geflogen.

Viele Grüße,
Christian

[Dennis]

Hi Christian,

Punkt 1 wirst Du aber alleine durch Deaktivieren der .htaccess-Funktionalität (AllowOverride None) nicht los, denn jedes Verzeichnis wird IMMER angesehen wegen Symlinks *AUSSER* FollowSymLinks ist als Option gesetzt […]

Deine Meinung deckt sich sicherlich in den größten Teilen mit meiner, aber diese Argumentation hier verstehe ich nicht. In der Apache-Doku heißt es dazu:

There are two main reasons to avoid the use of .htaccess files.

The first of these is performance. When AllowOverride is set to allow
  the use of .htaccess files, Apache will look in every directory for .htaccess
  files. Thus, permitting .htaccess files causes a performance hit, whether or
  not you actually even use them! Also, the .htaccess file is loaded every time
  a document is requested.

Further note that Apache must look for .htaccess files in all higher-level
  directories, in order to have a full complement of directives that it must apply.

[…]

The use of .htaccess files can be disabled completely by setting the
  AllowOverride  directive to none

Quelle: http://httpd.apache.org/docs/2.2/howto/htaccess.html

Das verstehe ich so, dass AllowOverride None der Performance förderlich ist.

Viele Grüße,
  ~ Dennis.

[Christian Seiler]

Hallo Dennis,

Das verstehe ich so, dass AllowOverride None der Performance förderlich ist.

Wenn keine .htaccess da ist und Options +FollowSymLinks gesetzt ist, ja. Wenn Options -FollowSymLinks oder Options +SymLinksIfOwnerMatch gesetzt ist, muss der Apache ja tortzdem jedes Verzeichnis lstat()en, um Symlinks zu finden, der Aufwand, dann nochmal ein stat(verzeichnis/.htaccess) hinterherzujagen, dürfte kaum messbar sein, daher ist es relativ blödsinnig, AllowOverride None OHNE Options +FollowSymLinks aus PERFORMANCE-Gründen zu machen, wenn keine .htacess vorhanden ist (AllowOverride None kann aus SICHERHEITS-Gründen natrülich schon sinnvoll sein ;-)). Und Options +FollowSymLinks will man idR. aus Sicherheitsgründen nicht, außer man braucht es explizit.

Viele Grüße,
Christian

[Dennis]

Hi Christian,

Wenn Options -FollowSymLinks oder Options +SymLinksIfOwnerMatch gesetzt ist, muss der Apache ja tortzdem jedes Verzeichnis lstat()en, um Symlinks zu finden, der Aufwand, dann nochmal ein stat(verzeichnis/.htaccess) hinterherzujagen, dürfte kaum messbar sein […]

Ok, es scheint mir also darin begründet zu sein, dass der Apache für das Erkennen der symbolischen Links ebenfalls rekursiv durch alle Verzeichnisse gehen muss. Das war mir in der Form nicht bewusst, ich hatte mir einfach ein doesPathContainSymLink() vorgestellt ;-)

Und Options +FollowSymLinks will man idR. aus Sicherheitsgründen nicht, außer man braucht es explizit.

Ich hatte seinerzeit mal bei Occuris das CForum installiert und dabei war mir vorgeschlagen worden das Forum zentral irgendwo zu installieren und dann für jede Forums-Instanz an der entsprechenden Stelle im „URL-Filesystem” einen Symlink zu setzen. Folglich schien Occuris symbolische Links erlaubt zu haben.

Welche Gründe sprechen denn für ein Options -FollowSymLinks? In einem System, wo der Apache Scripte schön brav unter den Rechten des Users ausführt (suExec, suPHP) kann der User doch mit FollowSymLinks auch nicht mehr machen, als er nicht auch schon so mit seinem Benutzeraccount auf der Shell machen könnte.

Viele Grüße,
  ~ Dennis.

[Christian Seiler]

Hallo Dennis,

Welche Gründe sprechen denn für ein Options -FollowSymLinks? In einem System, wo der Apache Scripte schön brav unter den Rechten des Users ausführt (suExec, suPHP) kann der User doch mit FollowSymLinks auch nicht mehr machen, als er nicht auch schon so mit seinem Benutzeraccount auf der Shell machen könnte.

Szenario: User A und B sind auf dem Server. User A liegt in /var/www/usera/..., User B in /var/www/userb/.... User A kann den Inhalt von userb per Default nicht lesen (der Apache aber schon). Stell Dir vor, User A weiß nun (z.B. durch eine PHP-Fehlermeldung im Browser), dass die Konfigurationsdatei für den DB-Zugriff von User B unter /var/www/userb/foo/bar/config.php zu erreichen ist. Dann kann er bei sich einen Symlink (das Ziel ist ja erstmal egal) auf eben diese Datei anlegen:

ln -s /var/www/userb/foo/bar/config.php /var/www/usera/htdocs/mysql-konfiguration.txt

User A kann den Symlink natürlich nicht lesen. Wenn jedoch +FollowSymLinks aktiviert ist, prüft der Apache den Symlink nicht und liefert (die Endung der Datei ist ja .txt, den Link liest der Apache ja nicht aus, weil er ihm immer folgt) beim Zugriff auf die Domain von User A die config.php als Textdatei aus. Was dann dazu führt, dass User B Zugriff auf die Datenbankzugangsdaten von User A hat.

Das "tolle" ;-) ist, dass das sogar mit Links auf z.B. .htaccess oder .htpasswd geht, obwohl .ht* verboten ist! Weil der Link eben NICHT auf .ht anfängt!

Zudem kann man sich Szenarien vorstellen, in denen man als Angreifer (der keinen Account hat) Scripte dazu bringen kann, Symlinks auf z.B. /etc/passwd zu setzen, über die man dann von außen darauf zugreifen kann.

Daher: +FollowSymlinks sollte man NUR DANN aktivieren, wenn man weiß was man tut. Es gibt schließlich SymlinksIfOwnerMatch, die für ExecCGI, mod_rewrite und normale Symlinks MEHR ALS AUSREICHEN. Und seit Apache 2.2 kann man übrigens bei AllowOverride angeben, welche Options ein User setzen darf (AllowOverride Options=SymlinksIfOwnerMatch,MultiViews,...), d.h. AllowOverride Options kann teilweise aktiviert sein und somit dem User Konfigurationsmöglichkeiten bieten, ohne dass damit eine Sicherheitslücke geschaffen wird, weil der User +FollowSymlinks aktivieren kann.

Viele Grüße,
Christian

[Dennis]

Hi Donald,

Nun wird mir gesagt, dass ich damit den Apache deutlich bremsen würde, da diese .htaccess-Datei jede Menge I/O auf dem Server produziert (muss ja dauernd gelesen werden).

Das stimmt so erst mal nicht - moderne Betriebssysteme cachen die Zugriffe auf häufig benötigte Dateien, sodass nicht jeder Leseversuch des Apaches wirklich einen Festplattenzugriff erzeugt. Desweiteren könnte ich mir sehr gut vorstellen, dass der Apache die Daten aus der .htaccess auch zumindest kurzzeitig cached.

Ist das merklich? [...] Oder soll der Bereich ausgelagert werden um dann als Virtueller Host anderst behandelt zu werden?

Das eigentliche Problem ist ein anderes. Auch wenn die .htaccess Datei nicht existiert, dann muss der Apache natürlich einen entsprechenden Betriebssystem-Aufruf starten um dies erst mal herauszufinden. Sprich: Der Apache muss in jedem Fall (egal ob die .htaccess existiert oder nicht) nachschauen ob eine existiert.

Dieses Problem wirst du immer haben, solange du es nicht mit AllowOverride None umgehst. Dann guckt der Apache grundsätzlich nicht nach einer .htaccess-Datei (somit Performance-Gewinn), dafür kannst du keine Konfigurationen ohne Server-Neustart vornehmen.

Für eine stark frequentierte Seite würde ich allerdings in der Tat dazu tendieren, AllowOverride auf None zu setzen und sämtliche notwendigen Konfiguration im VirtualHost in einem Directory-Container vorzunehmen. Dies hat unter anderem den Vorteil, dass dir nicht jemand durch Unterschieben einer fremden .htaccess das System lahmlegen kann.

Viele Grüße,
  ~ Dennis.

[Sven Rautenberg]

Moin!

Ich habe ein administratives Unterverzeichnis meines gehosteten Verzeichnisses (Apache) mit .htaccess geschützt. Nun wird mir gesagt, dass ich damit den Apache deutlich bremsen würde, da diese .htaccess-Datei jede Menge I/O auf dem Server produziert (muss ja dauernd gelesen werden).

Ist das so?

Ja, auf jeden Fall. Wenn der Apache konfiguriert ist, dass er nach .htaccess-Dateien suchen soll, dann sucht er in dem jeweiligen Verzeichnis und allen übergeordneten Verzeichnissen nach existierenden Dateien. Und wenn er welche findet, dann liest er sie ein und verarbeitet ihren Inhalt - und zwar bei jedem Request neu.

Ist das merklich?

Hängt davon ab, was du unter "merklich" verstehst - und natürlich auch, wie ausgelastet der Server sonst so ist.

Wie machen das grosse Seiten mit Mio Zugriffen am Tag?

Die nutzen explizit keine .htaccess-Dateien, sondern konfigurieren alle notwendigen Dinge in der normalen Server-Konfigurationsdatei. Die wird einmal beim Serverstart eingelesen und gilt ab dann. Änderungen erfordern einen Serverneustart, aber sowas kommt ja nicht sehr oft vor.

Oder soll der Bereich ausgelagert werden um dann als Virtueller Host anderst behandelt zu werden?

Das bringt dir gar nichts. Der Knackpunkt ist: Erlaubt der Server grundsätzlich .htaccess-Dateien, ja oder nein? Bei ja hast du bei jedem Request die Suche nach den Dateien, egal ob es sie gibt, oder nicht.

- Sven Rautenberg

[Donald]

Hallo Zusammen,

hab erst sehr spät wieder hier reingeguckt wegen Krankheit. Vielen Dank für die Erklärungen. Ich denke, ich werde versuchen auf die .htaccess zu verzichten. Es ging mir tatsächlich um den Schutz eines administrativen Verzeichnisses. Da ich alles mit PHP mache, werde ich da was basteln...

Grüsse,

Volker

[Sven Rautenberg]

Moin!

hab erst sehr spät wieder hier reingeguckt wegen Krankheit. Vielen Dank für die Erklärungen. Ich denke, ich werde versuchen auf die .htaccess zu verzichten. Es ging mir tatsächlich um den Schutz eines administrativen Verzeichnisses. Da ich alles mit PHP mache, werde ich da was basteln...

Dann hast du nicht richtig verstanden, was wir dir versuchten zu sagen.

Die Aussage war: Der .htaccess-Mechanismus kostet auch bei seiner Nichtbenutzung Performance, solange er nicht explizit komplett abgeschaltet ist.

Kannst du ihn komplett abschalten? Wenn nein, dann spricht absolut nichts dafür, .htaccess nicht zu benutzen, weil die dafür notwendige Zusatzarbeit die Serverperformance nur in ganz geringem Maße beeinflußt.

Du stehst vor der Wahl, mit .htaccess auf einfachste Weise einen sicheren Schutz für alle im Verzeichnis und den Unterverzeichnissen enthaltenen Ressourcen zu konfigurieren, oder dir selbst etwas auszudenken, was erstmal nur ausgewählte PHP-Skripte schützt und unter Umständen auch noch dumme Sicherheitslücken hat. Außerdem erfordert die Prüfung der Zugriffsberechtigung in PHP natürlich auch Extra-Performance, so dass du am Ende höchstwahrscheinlich gar nichts gewinnst.

- Sven Rautenberg