---

Hej

Er der nogle, der har erfaringer med, hvor mange resurser mod_rewrite
sluger? Jeg står i den situation, at jeg skal lave et site, der får
pænt meget trafik (10-15 GB om måneden - nogle af dem er dog billeder,
men jeg kender ikke det præcise antal sidevisninger), og kunden vil
have et databasedrevent site, men insisterer samtidig på, at filerne
skal ligge som almindelige filer (query string er bandlyst). Min
oprindelige tanke var at lade PHP skrive nogle HTML- eller PHP-filer
direkte på disken, men det er ikke en optimal løsning, så jeg kunne
også gøre det vha. mod_rewrite. Spørgsmålet er, om det rent
resursemæssigt er et problem at bruge mod_rewrite på hele sitet, når
der er så forholdsvist mange sidevisninger?

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 15 May 2002 11:15:54 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Hej
>
>Er der nogle, der har erfaringer med, hvor mange resurser mod_rewrite
>sluger?

der er et minimalt overhead... skulle efter min bedste overbevisning
ikke betyde noget i praksis

>Jeg står i den situation, at jeg skal lave et site, der får
>pænt meget trafik (10-15 GB om måneden - nogle af dem er dog billeder,
>men jeg kender ikke det præcise antal sidevisninger), og kunden vil
>have et databasedrevent site, men insisterer samtidig på, at filerne
>skal ligge som almindelige filer (query string er bandlyst).

eh... skal det både være dynamisk (db) og m. statiske filer?... Hvor
statiske er filerne - as in skal de genereres een gang i døgnet eller?

> Min
>oprindelige tanke var at lade PHP skrive nogle HTML- eller PHP-filer
>direkte på disken, men det er ikke en optimal løsning, så jeg kunne
>også gøre det vha. mod_rewrite. Spørgsmålet er, om det rent
>resursemæssigt er et problem at bruge mod_rewrite på hele sitet, når
>der er så forholdsvist mange sidevisninger?

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

Thomas Jensen - pil.dk skrev:
>
> eh... skal det både være dynamisk (db) og m. statiske filer?... Hvor
> statiske er filerne - as in skal de genereres een gang i døgnet eller?

Tanken var, at en statisk HTML-/PHP-fil bliver genereret i samme
øjeblik, brugeren inde på administrationssiden har trykket på
submitknappen efter en ændring af siden. Det er bestemt ikke optimalt
at blande statiske filer med databaseting på den måde, så jeg ville
langt foretrække mod_rewrite, og det gør jeg så nok også. Tak for
svaret.

--
Jonas Koch Bentzen

http://understroem.dk/

---

Jonas Koch Bentzen wrote:

> Tanken var, at en statisk HTML-/PHP-fil bliver genereret i samme
> øjeblik, brugeren inde på administrationssiden har trykket på
> submitknappen efter en ændring af siden. Det er bestemt ikke optimalt
> at blande statiske filer med databaseting på den måde, så jeg ville
> langt foretrække mod_rewrite, og det gør jeg så nok også. Tak for
> svaret.

Ved den løsning vil nogle rewrites være en dråbe i resursehavet i
forhold til at skulle lave et kald til database. Hvor mange hits i
sekundet er der tale om? Du nævnte kun trafikmængden, hvilket siger ret
lidt om hvor mange hits der er tale om.

--
Hroi Sigurdsson hroi@asdf.dk
Danske nyhedsfeeds i RSS-format: http://asdf.dk/rss/da/

---

Hroi Sigurdsson skrev:
>
> Ved den løsning vil nogle rewrites være en dråbe i resursehavet i
> forhold til at skulle lave et kald til database. Hvor mange hits i
> sekundet er der tale om? Du nævnte kun trafikmængden, hvilket siger
> ret lidt om hvor mange hits der er tale om.

Som jeg også sagde, så kender jeg ikke antallet af sidevisninger. Jeg
gætter mig bare til, at det er forholdsvist stort.

--
Jonas Koch Bentzen

http://understroem.dk/

---

Jonas Koch Bentzen <ingen.emailadresse@eksempel.dk> wrote in
news:abt90b$pp0$1@sunsite.dk

> men insisterer samtidig på, at filerne
> skal ligge som almindelige filer (query string er bandlyst).

Kan du ikke bare bruge tricket med at lave en php fil uden efternavn
og så bruge $PATH_INFO til at finde ud af hvilken side den skal vise
?

--
Henrik Stidsen | HS235-DK | Ikke eksisterende samleobjekt
http://min.hjemmeside.er.paa.http.kolon.2-x-skraastreg.susie.dk/
"These opinions are my own, though for a small fee they
be yours too." -- Dave Haynie

---

Henrik Stidsen skrev:

> Jonas Koch Bentzen <ingen.emailadresse@eksempel.dk> wrote in
> news:abt90b$pp0$1@sunsite.dk
>
>> men insisterer samtidig på, at filerne
>> skal ligge som almindelige filer (query string er bandlyst).
>
> Kan du ikke bare bruge tricket med at lave en php fil uden efternavn
> og så bruge $PATH_INFO til at finde ud af hvilken side den skal vise
> ?

Nej, for filsystemet *skal* se således ud:

/Noget/Noget/Andet
/EtEllerAndet/
/NogetHeltAndet/

osv.

Det betyder, at jeg skal have en PHP-fil liggende for hver "mappe" i
roden.

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 15 May 2002 17:06:18 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Nej, for filsystemet *skal* se således ud:
>
>/Noget/Noget/Andet
>/EtEllerAndet/
>/NogetHeltAndet/
>
>Det betyder, at jeg skal have en PHP-fil liggende for hver "mappe" i
>roden.

Behøver jeg at sige, at MultiViews stadigvæk er din ven? :)

Her skal filerne:
Noget.php
EtEllerAndet.php
NogetHeltAndet.php
... blot oprettes. Så kan man uden problemer, uden videre gå ind på
/Noget
/Noget/
/Noget/Noget
/Noget/Noget/Andet
.... etc.

Hvilket problem er det, du prøver at løse? MultiViews kan fjerne
synligheden af ".php", og $PATH_INFO kan meget vel fungere som en
simpel $QUERY_STRING.

--
- Peter Brodersen

---

Peter Brodersen skrev:

> On Wed, 15 May 2002 17:06:18 +0200, Jonas Koch Bentzen
> <ingen.emailadresse@eksempel.dk> wrote:
>
>>Nej, for filsystemet *skal* se således ud:
>>
>>/Noget/Noget/Andet
>>/EtEllerAndet/
>>/NogetHeltAndet/
>>
>>Det betyder, at jeg skal have en PHP-fil liggende for hver "mappe" i
>>roden.
>
> Behøver jeg at sige, at MultiViews stadigvæk er din ven? :)
>
> Her skal filerne:
> Noget.php
> EtEllerAndet.php
> NogetHeltAndet.php
> .. blot oprettes.

Ja, det er jo det, jeg siger : ) At man skal have PHP-fil liggende for
hver mappe i roden. Menuen er ikke fast - administratoren skal kunne
oprette en ny via browseradministrationen. Derefter skal
administrationsscriptet så skrive en fil ned på disken, hvis
administratoren opretter en ny "mappe". Det er ikke en fed løsning
efter min mening. Problemet er kort sagt, at kunden vil have et 100%
databasedrevet site - med et 100% "almindeligt" filsystem (det behøver
dog ikke at være rigtige filer - det må godt være mod_rewrite).

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 15 May 2002 18:18:40 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Ja, det er jo det, jeg siger : ) At man skal have PHP-fil liggende for
>hver mappe i roden.

Overordnet set vil jeg ikke tro at mod_rewrite er så slem, hvis du
blot smider alting hen til samme fil, uden at blande regulære udtryk
ind over.

Endnu et stunt, som jeg selv bruger på http://shor.ter.dk/ som
eksperiment, er at lade 404-handleren lave arbejdet. Jeg har således
links i stil med:
http://shor.ter.dk/550844953
... altså uden "?" eller lignende i starten.

Forvent dog at din errorlog bliver fyldt op.

--
- Peter Brodersen

---

Peter Brodersen skrev:
>
> Overordnet set vil jeg ikke tro at mod_rewrite er så slem, hvis du
> blot smider alting hen til samme fil, uden at blande regulære udtryk
> ind over.

Hvordan kan jeg undgå at få regulære udtryk ind over? Bruger mod_rewrite
ikke altid regulære udtryk?

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 15 May 2002 18:46:59 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Hvordan kan jeg undgå at få regulære udtryk ind over? Bruger mod_rewrite
>ikke altid regulære udtryk?

... okay, så komplekse regulære udtryk. Evalueringstiden af en regex
stiger drastisk med kompleksiteten, men for et simpelt udtryk er det
næppe den store belastning, der kommer ind over, fx:

RewriteRule   /   parser.php

Vel tager det da ressourcer at starte en regex-motor op, men der er
langt flere faktorer efterfølgende, fx om man capture'r, har
backreferences, laver case-insensitive-matches, etc.

Kan du ikke evt. lege lidt med ab hhv. med og uden rewriteengine'n
aktiveret, og se om der er nogen nævneværdig forskel? Det, du er
interesseret i, er vel netop rewriteenginens indflydelse på
performance.

--
- Peter Brodersen

---

Peter Brodersen wrote:

> Vel tager det da ressourcer at starte en regex-motor op, men der er
> langt flere faktorer efterfølgende, fx om man capture'r, har
> backreferences, laver case-insensitive-matches, etc.

Samt hvis man specificerer reglerne i httpd.conf (dvs. ikke runtime i
..htaccess) vil mod_rewrite precompile de regulære udtryk.

> Kan du ikke evt. lege lidt med ab hhv. med og uden rewriteengine'n
> aktiveret, og se om der er nogen nævneværdig forskel? Det, du er
> interesseret i, er vel netop rewriteenginens indflydelse på
> performance.

Mit gæt vil være at overheadet ikke vil kunne måles hvis der samtidig
bruges databasekald.

--
Hroi Sigurdsson hroi@asdf.dk
Danske nyhedsfeeds i RSS-format: http://asdf.dk/rss/da/

---

On Thu, 16 May 2002 02:00:27 +0200, Hroi Sigurdsson <hroi@asdf.dk>
wrote:

>> Kan du ikke evt. lege lidt med ab hhv. med og uden rewriteengine'n
>> aktiveret, og se om der er nogen nævneværdig forskel? Det, du er
>> interesseret i, er vel netop rewriteenginens indflydelse på
>> performance.
>Mit gæt vil være at overheadet ikke vil kunne måles hvis der samtidig
>bruges databasekald.

Det lyder også som mit gæt. Og ved nærmere eftertanke burde man jo
netop kunne se en procentvis stor forskel, hvis man har et "tomt
site", og det eneste, der kunne belaste, var rewrite-stuntet. Sådan
vil det selvfølgelig ikke forholde sig i praksis, hvor der netop er
mange, mange andre faktorer. Og så burde belastningen af
rewrite-stuntet netop drukne i så meget andet.

--
- Peter Brodersen

---

On Wed, 15 May 2002 18:18:40 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:


>efter min mening. Problemet er kort sagt, at kunden vil have et 100%
>databasedrevet site - med et 100% "almindeligt" filsystem (det behøver
>dog ikke at være rigtige filer - det må godt være mod_rewrite).

som en nær ven ville sige: "use the filesystem as a database".

han er godt nok besværlig ham din kunde hva' :)

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

Thomas Jensen - pil.dk skrev:
>
> som en nær ven ville sige: "use the filesystem as a database".

Hvordan skal det forstås?
>
> han er godt nok besværlig ham din kunde hva' :)

Ja, at kombinere et 100% browseradministreret site med URI'er som f.eks.
http://eksempel.dk/Biler/Ford/fiesta.php og
http://eksempel.dk/Cykler/Kildemoes/ er sådan set lidt besværligt : )

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 15 May 2002 18:49:16 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Thomas Jensen - pil.dk skrev:
>>
>> som en nær ven ville sige: "use the filesystem as a database".
>
>Hvordan skal det forstås?

Det er blot hans mantra... specielt når kunder m. heavy-loadløsninger
og store budgetter begynder at tale om store komplekse databasesetups.

Men seriøst kan jeg ikke se hvad din kunde i dette tilfælde vil opnå
v. både at have ting i en database og i et filsystem. Personligt ville
jeg så nok tilstræbe at stille ham spørgsmål så han måtte foretage et
valg. Hvad vindes eksempelvis v. at smide det hele i en database(?).

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

Thomas Jensen - pil.dk skrev:
>
> Men seriøst kan jeg ikke se hvad din kunde i dette tilfælde vil opnå
> v. både at have ting i en database og i et filsystem. Personligt ville
> jeg så nok tilstræbe at stille ham spørgsmål så han måtte foretage et
> valg. Hvad vindes eksempelvis v. at smide det hele i en database(?).

Jeg har diskuteret det med kunden i over et halvt år. Nu gider jeg ikke
mere : ) Han er urokkelig og desværre lige så stædig som mig.

--
Jonas Koch Bentzen

http://understroem.dk/

---

I apache's httpd.conf kan du sætte ServerRoot til et php script.
Et eksempel er:

<VirtualHost 192.168.1.2>
ServerName test.ordo.dk
DocumentRoot /www/default/docroot.php
</VirtualHost>

se http://test.ordo.dk/sejt/nok?tror+jeg+da

Nu vil alt uderligere i URL'en blive tilføjet til PATH_INFO og
du kan selvfølgelig stadig tilgå variable i URL'en osv.
docroot.php ser sådan ud:

<?php

echo "Velkommen til docroot.php - PATH_INFO er $_SERVER[PATH_INFO] og
QUERY_STRING er $_SERVER[QUERY_STRING]!";

?>

HTH

--
-
Lars
http://coder.dk/sohofaq.php - Uofficiel WOL SOHO 77 FAQ
http://wshlman.moons.dk/ - Say goodbye to GameSpy - A Free Half Life
Manager!
To mail me remove your-pants.

---

Peter Brodersen <professionel@nerd.dk> wrote in
news:l_uE8.4130$4f4.256096@news000.worldonline.dk

> Hvilket problem er det, du prøver at løse? MultiViews kan fjerne
> synligheden af ".php", og $PATH_INFO kan meget vel fungere som en
> simpel $QUERY_STRING.

Der er problemer med $PATH_INFO hvis man "bare" bruger multiviews til
at at fjerne .php - det er ikke altid den kan finde ud af det så vidt
jeg har erfaret...

--
Henrik Stidsen | HS235-DK | Ikke eksisterende samleobjekt
http://min.hjemmeside.er.paa.http.kolon.2-x-skraastreg.susie.dk/
"These opinions are my own, though for a small fee they
be yours too." -- Dave Haynie

---

On Thu, 16 May 2002 12:24:09 GMT, Henrik Stidsen <spamtrap@spammer.dk>
wrote:

>Der er problemer med $PATH_INFO hvis man "bare" bruger multiviews til
>at at fjerne .php - det er ikke altid den kan finde ud af det så vidt
>jeg har erfaret...

Det har jeg ikke oplevet. Tænker du ikke "bare" på Apache
1.3.22-problemet, hvor man med MultiViews ikke fik $QUERY_STRING
overført til evt. serverside-parsere?

--
- Peter Brodersen

---

Peter Brodersen <professionel@nerd.dk> wrote in
news:D0SE8.4612$4f4.309659@news000.worldonline.dk

>>Der er problemer med $PATH_INFO hvis man "bare" bruger
>>multiviews til at at fjerne .php - det er ikke altid den kan
>>finde ud af det så vidt jeg har erfaret...
>
> Det har jeg ikke oplevet. Tænker du ikke "bare" på Apache
> 1.3.22-problemet, hvor man med MultiViews ikke fik $QUERY_STRING
> overført til evt. serverside-parsere?

Det kan godt være det er det jeg husker - det lyder rigtigt

--
Henrik Stidsen | HS235-DK | Ikke eksisterende samleobjekt
http://min.hjemmeside.er.paa.http.kolon.2-x-skraastreg.susie.dk/
"These opinions are my own, though for a small fee they
be yours too." -- Dave Haynie

---

On Wed, 15 May 2002 17:06:18 +0200, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Nej, for filsystemet *skal* se således ud:
>
>/Noget/Noget/Andet
>/EtEllerAndet/
>/NogetHeltAndet/

Det slog mig pludselig, at Apache da måtte kunne hjælpe på det punkt,
og ved at kigge diverse Apache-udvidelser igennem, ringede en klokke.

Du kan for dit webkatalog blot lave en handler, der har et PHP-script
som action. I sin helt simple form:


# ADVARSEL - KØR IKKE DETTE UDEN VIDERE - LÆS LÆNGERE NEDE
Action my-php-parser /index.php
SetHandler my-php-parser


SetHandler sørger for at alle requests i det katalog bliver fanget
(hvor AddHandler blot gør det for filer med en bestemt extension, fx
..html).

CAVEAT: Ovenstående er ikke nok, men vil gå i løkke, idet når den
forsøger internt at fange index.php, falder det request også for vores
directive, og så går Apache ganske enkelt i løkke. Løsningen er så fx
at have et Files-directive, der omgår index.php. Jeg har ledt lidt, og
kan faktisk ikke finde et "not match", derfor det lidt rodede
eksempel, der udelukker filnavn-requests, der slutter på "php":

<FilesMatch "^(.|..|.*[^p][^h][^p])$">
Action my-php-parser /index.php
SetHandler my-php-parser
</FilesMatch>

Kræmmeragtigt, men jeg kunne ikke lige finde på noget elegant her om
morgenen (og så bruger den endda regex apopros den tidligere
diskussion :)

Du kan se det i simpel drift på:
http://defaul.ter.dk/
.... ja, eller selvfølgelig hvad som helst andet:
http://defaul.ter.dk/Noget/
http://defaul.ter.dk/Noget/Noget/Andet
http://defaul.ter.dk/EtEllerAndet/
http://defaul.ter.dk/DerLiggerIkkeAndreFiler/
http://defaul.ter.dk/BuyMyStuff/NotExist.htm?ProductID=10&UserID=5

--
- Peter Brodersen