[Terrorbeat]

HI

Ist das eine gute URL?

localhost/admin/modul/index.php/ein/12/query/

speziell mein ich das nach der Datei noch weitere path angegeben werden, kommen Suchmaschinen damit klar?

[Murdoc]

weitere infos nach dem dateinamen ist fester bestandteil des CGI rfc. warum sollten suchmaschinen damit nicht klar kommen?

schimpft sich PATH_INFO und wird von vielen cms verwendet, weil damit mod_rewrite nicht mehr benötigt wird um "benutzer"-freundliche uris zu bauen.

ich persönlich mag mod_rewrite lieber. macht aber nur sinn wenn man vollen zugriff auf den server hat, denn mod_rewrite mittels .htaccess ist lahm.

[Terrorbeat]

Irgendwie sah das heute Mittag noch total komisch aus ich war mir unsicher

Ich habe da so nen Problem mit einer Rewrite rule bei der du mir sicher helfen kannst...
Wen ich folgende Adresse aufrufe: http://localhost/cms/datei.php

 ([0-9a-z]+).php index.php?warum=$1 [QSA]

Warum gibt dann die PHP Variable $_SERVER['QUERY_STRING'] folgendes aus:

warum=index&warum=datei

der erste Parameter soll da nicht stehen.

Das sieht nicht gesund aus, da soll nur warum=datei stehen.

----- (eigentlich selbe nochmal)

auch bei komplexeren rewrite Rules wie dieser wird der Query teil dupliziert und ausgerechnet die dritte zwischengespeicherte variable $3 in die get variable site eingefügt.

RewriteRule ^(admin/)?([-0-9a-zA-Z/]*?)/?([0-9a-zA-Z]+)\.(htm|html|php)/?([-0-9a-zA-Z/]*)$ $1index.php?site=$3&modul=$2&query=$5 [QSA]

bei einem aufruf wie:

http://localhost/CMS/modul1/modul2/datei.php/query1/query2/?query=true

site=index&modul=&query=&site=datei&modul=modul1/modul2&query=query1/query2/&query=true

[Murdoc]

du kannst auf den query-string innerhalb eines rewrite-ausdrucks nicht zugreifen. das musst du separat mittels rewritecond abfragen.

btw: warum nutzt du mod_rewrite wenn du die sachen doch mit php parsen kannst wie du lustig bist?
PATH_INFO mittels mod_rewrite zu verarbeiten is doch bescheuert

[Terrorbeat]

also ich will doch überhaupt gar nicht den Query string aufgreifen. Das Problem scheint mir zu sein das ich intern auf

http://localhost/cms/index.php?warum=index&warum=datei

geleitet werde. Da ist halt ein warum=index zu viel und ich verstehe nicht weshalb.
(Ohne das [QSA] am Ende wäre es nur der warum=index part.)


Ob PHP oder rewrite is doch egal. Finde es eigentlich ganz gut mit mod_rewrite

[Murdoc]

was du eingibst:

http://localhost/foo/bar.php?baz=1

was du in rewriteCond abfragen kannst:

/foo/bar.php

d.h. der query-string "?baz=1" ist da nicht zu finden und du kannst den dort auch nicht entfernen.

mit [QSA] sagst du dem modul nur, dass es "?baz=1" wieder anhängen soll. es wird nicht geprüft ob du ein key=value paar bereits selber gesetzt hast.

es wird lediglich geprüft ob "?" oder "&" am anfang verwendet werden soll.

[QSA] = QueryStringAppend (!= Merge)

und deswegen auch die anmerkung zwecks php.
wenn du die sachen mit php verarbeitest, kannst du dir ganz bequem alle variablen selber
zusammenstellen (inkl. query) und an deine controller weiterreichen.

[Terrorbeat]

das gefällt mir alles nicht. Ich habe einen Aufruf komplet ohne query-string: http://localhost/cms/datei.php
da is also nichts was QSA anhängen kann. Total kommisch ist eben das wen ich QSA testweise entferne das mein künstlicher query den wert "index" und nicht "datei" bekommt. Da ich ja jetzt weiß das QSA anfügt und mein zweites Beispiel von oben den kompletten query einmal dupliziert scheint es ein verdoppelter Aufruf zu sein. Eine Lösung habe ich trotzdem nicht.

[theQuest]

Ich würde in einem Backend immer auf ModRewrite verzichten. Ergibt m.M. nach überhaupt keinen Sinn. Belastet nur unnötig den Indianer.
Das viel mir nur ein, als ich als Modul "Admin" gelesen habe.

[Murdoc]

das ist quatsch. mod_rewrite is schneller als ein php-router, solange es in httpd/vhosts config definiert ist.

sobald man die regeln aber in eine .htaccess datei ablegt kann es schon sein, dass das ganze ein wenig träger daher kommt.

warum das so ist:
httpd/vhost config wird beim start des server geladen (= 1x), .htaccess bei jeder anfrage erneut.

die "belastung" des indianers hält sich aber in grenzen.
ich werde nach feierabend mal nen benchmark durchlaufen lassen.

[theQuest]

Meist werden die Regeln aber eben im Verzeichnis in einer htaccess abgelegt. Nur ganz selten landen diese doch in der Config. Wenn dann noch sehr komplexe Regeln genutzt werden, die viele Eventualitäten berücksichtigen, wäre der native Zugriff auf die PHP-Datei schneller. Wobei wir uns hier wieder in Bereichen bewegen, die man bei den "normalen Seiten" nicht berücksichtigt / kennt.

[Murdoc]

dass die regln oft in .htaccess abgelegt vergessen werden stimmt.

es funktioniert halt beides, und .htaccess bietet sich halt beim entwickeln der app an, da man den server nicht neu starten muss nur um an den regeln was zu schrauben.

wenn die app dann aber in den produktiveinsatz wechselt sollten die reglen fest mit in die httpd/vhost config wandern, einfach um unnötigen startup ballast zu vermeiden. da bekommt man ganz schnell einige 100 anfragen/s mehr ausgeliefert als sonst.

[theQuest]

Zitat von Murdoc

dass die regln oft in .htaccess abgelegt vergessen werden stimmt.

es funktioniert halt beides, und .htaccess bietet sich halt beim entwickeln der app an, da man den server nicht neu starten muss nur um an den regeln was zu schrauben.

wenn die app dann aber in den produktiveinsatz wechselt sollten die reglen fest mit in die httpd/vhost config wandern, einfach um unnötigen startup ballast zu vermeiden. da bekommt man ganz schnell einige 100 anfragen/s mehr ausgeliefert als sonst.

Na klar. Aber es ist halt ein Gedanke, den die wenigsten auffassen.

Konntest du den Benchmark machen?

[Murdoc]

Ohne mod_rewrite:
Requests per second: 3194.70 [#/sec] (mean)

Mit mod_rewrite:
Requests per second: 2293.45 [#/sec] (mean)

Mit mod_rewrite fest in httpd.conf eingebaut
Requests per second: 2512.42 [#/sec] (mean)

<Directory "/xampp/htdocs/test/rwt/mit_fixed/">
  RewriteEngine On
  RewriteBase /test/rwt/mit_fixed

  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^index/?$ app/index.php [QSA,L]
</Directory>

Mit nem php-router mittels PATH_INFO
Requests per second: 2288.20 [#/sec] (mean)

System: Win7 x64, RAM: 4GB, CPU: AMD P2 x4 (4x 3.2 GHZ)
AB: 1000 Anfragen, 100 Parallel, von 10 Versuchen jeweils das beste Ergebnis.
Host: localhost

Testdateien: http://www.xup.in/dl,91522045/rwt.7z/
Die kompletten logs von `ab` findet man in den Verzeichnissen.

Wenn es jemand besser/ausführlicher machen will: nur zu

[MArc]

Naja, die .htaccess-mod-rewrite-'optimierung' macht absolut kein Sinn, wenn man es auf PHP-Apps abfeuert, die nicht gerade nur "Hello World" ausgeben.
Hochgerechnet auf Apps, die eben mehr machen, schmaellert sich die 'Optimierung' auf nicht mehr Messbar.

Optimiert lieber den PHP-Code, anstatt mit so sinnlosen Mini-Optimierungen wie die .htaccess-Rules in Apache-Conf zu schieben.

1/3200 => 0.00031s => 0.31ms/4(kerne) => 0.077ms Ausfuehrungszeit.
1/2300 => 0.00043s => 0.43ms/4(kerne) => 0.107ms Ausfuehrungszeit.

Somit "verbraucht" mod_rewrite in der .htaccess Variante also 0.03ms mehr.

0.03ms. Mehr braucht denke ich nicht gesagt werden.

[theQuest]

Zitat von MArc

Naja, die .htaccess-mod-rewrite-'optimierung' macht absolut kein Sinn, wenn man es auf PHP-Apps abfeuert, die nicht gerade nur "Hello World" ausgeben.
Hochgerechnet auf Apps, die eben mehr machen, schmaellert sich die 'Optimierung' auf nicht mehr Messbar.

Optimiert lieber den PHP-Code, anstatt mit so sinnlosen Mini-Optimierungen wie die .htaccess-Rules in Apache-Conf zu schieben.

1/3200 => 0.00031s => 0.31ms/4(kerne) => 0.077ms Ausfuehrungszeit.
1/2300 => 0.00043s => 0.43ms/4(kerne) => 0.107ms Ausfuehrungszeit.

Somit "verbraucht" mod_rewrite in der .htaccess Variante also 0.03ms mehr.

0.03ms. Mehr braucht denke ich nicht gesagt werden.

Haben wir auch schon festgestellt. Es sind Optimierungen, die kaum jemand braucht, da die meisten Scripte nicht die Performancegrenzen eines Rechners erreichen. Dessen bin ich mir, und murdoc sich sicher auch, bewusst.

Aber es geht hier ja um die Theorie und wie man es richtig machen sollte.

Ist wie die theoretische Diskussion, dass PHP eigentlich nicht geeignet ist für Webangebote, da durch native(re) Sprachen eine bessere Performance erreicht werden würde. Da aber die Server eine riesige Leistung bereitstellen, die von keinem (guten) Script ausgeschöpft wird, bleiben solche Diskussionen immer theoretisch. Lediglich wenn sich ein Projekt wie Facebook aus einem Script entwickelt, beginnt man in solchen Dimensionen zu denken.

@Murdoc: Hätte mehr von der http-Conf-Einbindung erhofft Aber interessant ist natürlich der Router im Vergleich zur htaccess-Variante.

[Murdoc]

vielleicht bekomme ich raid mal dazu `ab` auf raidrush.ws abzufeuern, dort wird nämlich auch mod_rewrite eingesetzt (seit geraumer zeit auch fest eingebaut in vhost-config).

das stellt sich raus wie viel das in einer "realworld" webanwendung bringt.
vielleicht hat raid ja noch zahlen im kopf.

[theQuest]

Also der Benchmark wäre sehr interessant. Glaube aber nicht, dass sich raid an Zahlen erinnern kann. Auch wenn die Zugriffszahlen gigantisch sein dürften (ganzes Portal?), zeigen bisherige Benchmarks ja, dass nicht soo viel Spielraum ist, was die Laufzeit angeht. Kann mir aber große Gewinne im Puncto Serverlast vorstellen ("große").