---

Hey.

Jeg har læst er sted at hvis man konstant "escap'er" php koden,
så sløves afviklingen af den. Hvilket jo egentligt giver en hvis
form for mening F.eks.:

<?php
if (noget)
?>

html her

<?php
elseif (noget andet)
?>

mere html her

osv..

Problemet er bare at jeg samme dag læste et andet sted, at en
anden løsning med at lade php'en echo'e eller print'e større
mængder html ligeledes sløver afvikligen af php'en. F.eks.:

<?php
if (noget) echo 'html her'
elseif (noget andet) echo 'mere html'
?>

eller:

<?php
if (noget) print 'html her'
elseif (noget andet) print 'mere html'
?>

Spørgsmålet er så, kan man med sikkerhed sige hvilken løsning der
er hurtigst ? Er der en tommelfinger regel jeg ikke kender ?
Eller er det en vurdering fra gang til gang ? Og hvis så, hvad
tommelfingerregelen ?

På forhånd tak.

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

On Thu, 08 Jul 2004 10:06:22 +0000, [ x] wrote:

> Spørgsmålet er så, kan man med sikkerhed sige hvilken løsning der
> er hurtigst ? Er der en tommelfinger regel jeg ikke kender ?
> Eller er det en vurdering fra gang til gang ? Og hvis så, hvad
> tommelfingerregelen ?

Tommelfingerreglen er at du bare gør det der er lettest for dig i det
konkrete tilfælde. Forskellen i hastighed er så marginal, at det næsten
kommer ud på et.

--
Christian Jørgensen
http://www.razor.dk

Få kontrol over dine nyhedsbreve: <http://www.ebrev.info>

---

On Thu, 08 Jul 2004 12:08:28 +0200, Christian Joergensen wrote:

> Forskellen i hastighed er så marginal, at det næsten
> kommer ud på et.
Det er ikke en absolut korrekt udtalelse. Som hovedregel, ja, men for
sites med mange samtidige brugere, eller hvor mængden af behandlede data
er stor, er det ikke en marginal forskel. Læg så yderligere hertil, at
hvis man benytter en processorbaseret webserver, er overhead ved skabelsen
af en ny proces betydelig - relativt set, hvorfor hastigheden her vil
blive ramt ekstra hårdt.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Debian Hint #18: You can see all of the current bugs for a given package by
going to http://bugs.debian.org/

---

Michael Rasmussen wrote:

> Det er ikke en absolut korrekt udtalelse. Som hovedregel, ja, men for
> sites med mange samtidige brugere, eller hvor mængden af behandlede data
> er stor, er det ikke en marginal forskel. Læg så yderligere hertil, at

Hej,

Øhm, har du noget at bakke den udtalelse op med? Jeg kunne selvfølgelig
selv google, men hvis du skulle ligge inde med en eller anden
undersøgelse af forskellen, vil jeg da gerne se :)

> hvis man benytter en processorbaseret webserver, er overhead ved skabelsen
> af en ny proces betydelig - relativt set, hvorfor hastigheden her vil
> blive ramt ekstra hårdt.

??

Hvad har det at gøre med om data bliver outputtet af print/echo eller
ved at gå ud af php-mode..?

--
Mvh. Nezar Nielsen
http://fez.dk

---

On Thu, 08 Jul 2004 12:45:37 +0200, Nezar Nielsen wrote:

>
> Øhm, har du noget at bakke den udtalelse op med? Jeg kunne selvfølgelig
> selv google, men hvis du skulle ligge inde med en eller anden
> undersøgelse af forskellen, vil jeg da gerne se :)
>
Logisk deduktion. Hver gang du har start-phptag initieres en ny proces
eller tråd, hvori afvikles en php-session. Jo flere af disse samtidigt,
jo større hukommelsesforbrug, og jo større potentiel efterspørgsel
efter diskaccess. Er databehandlingen stor, vil php-processen alt andet
lige, skulle bruge mere hukommelse. Det samme må gælde for situationen
med mange samtidige brugere. Hvad diskaccess angår, vil nødvendigheden
for ekstra hukommelse skabe et proportionalt behov for swap - igen alt
andet lige. Dertil kan jo så tillægges, at hvis php-sessionen kræver
stor disktilgang - scanning af en katalog f.eks, vil dette ligge
yderligere beslag på diskadgangen - scsi-diske vil dog nok her kunne
afhjælpe noget - tmq (tagged message queuing). Sidste men ikke mindst har
operativsystemet også en øvre grænse for antallet af åbne
filer/processer pr. bruger - kan dog stilles individuelt).

>> hvis man benytter en processorbaseret webserver, er overhead
ved
>> skabelsen af en ny proces betydelig - relativt set, hvorfor hastigheden
>> her vil blive ramt ekstra hårdt.
>
> ??
Processor til forskel for tråd: Kopien fylder lige så meget som orginale
ved fork, mens i tråd deles datasegment og adresserum.
>
> Hvad har det at gøre med om data bliver outputtet af print/echo eller
> ved at gå ud af php-mode..?
Læs ovenfor.
--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Don't you feel more like you do now than you did when you came in?

---

Michael Rasmussen <mir@miras.org> writes:

> Hver gang du har start-phptag initieres en ny proces eller tråd,
> hvori afvikles en php-session.

Hvor har du det fra?

Og kan vi så ikke lige blive enige om, at de fleste webservere er
processorbaserede. Nogle af disse er så procesbaserede, mens andre er
trådbaserede

--
Med venlig hilsen
- Jacob Atzen

---

Michael Rasmussen <mir@miras.org> wrote in
news:pan.2004.07.08.11.29.28.352768@miras.org

> Hver gang du har start-phptag initieres en ny proces
> eller tråd, hvori afvikles en php-session.

Det lyder meget meget ulogisk - så det må du gerne bakke op med noget
dokumentation :)

--
Henrik Stidsen - http://hs235.dk/ - http://såkadulæredet.dk/
"Is everyone else in the world a moron, or is it just me?"
(Dilbert Newsletter)

---

On Thu, 08 Jul 2004 22:45:05 +0000, Henrik Stidsen wrote:

>
> Det lyder meget meget ulogisk - så det må du gerne bakke op med noget
> dokumentation :)
Har lige læst det igen, og kan se, at man ikke skal skrive tekniske
forklaringer, når man er på vej ud af døren

Der skulle have stået: Hver gang en fil forespørges af en
klient, der indeholder et start-phptag ....

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Your aim is high and to the right.

---

Michael Rasmussen <mir@miras.org> wrote in
news:pan.2004.07.08.22.52.14.636248@miras.org

> Har lige læst det igen, og kan se, at man ikke skal skrive tekniske
> forklaringer, når man er på vej ud af døren

Ja det er jo bare en af de tilstande hvor man skal passe på - sent på
natten (som det er nu) kan også være farligt :)

> Der skulle have stået: Hver gang en fil forespørges af en
> klient, der indeholder et start-phptag ....

Den behøver vel ikke indeholde et start-tag ? En .php fil der ikke
indeholder noget PHP kode bliver jo alligevel kørt gennem parseren.

--
Henrik Stidsen - http://hs235.dk/ - http://såkadulæredet.dk/
"Is everyone else in the world a moron, or is it just me?"
(Dilbert Newsletter)

---

On Fri, 09 Jul 2004 01:28:35 +0000, Henrik Stidsen wrote:

>
> Den behøver vel ikke indeholde et start-tag ? En .php fil der ikke
> indeholder noget PHP kode bliver jo alligevel kørt gennem parseren.
Her er jeg ikke sikker, men jeg mener, apache kun redelegerer efter behov,
altså kun hvis der rent faktisk findes instruktioner omkrinset af et
start og sluttag. Anderledes forholder det sig med cgi, hvor der jo af
gode grunde ikke er angivelse af start og slut

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Debian Hint #6: There is no hint #6.

---

Michael Rasmussen <mir@miras.org> wrote in
news:pan.2004.07.09.07.46.07.542611@miras.org

> Her er jeg ikke sikker, men jeg mener, apache kun redelegerer
> efter behov, altså kun hvis der rent faktisk findes
> instruktioner omkrinset af et start og sluttag. Anderledes
> forholder det sig med cgi, hvor der jo af gode grunde ikke er
> angivelse af start og slut

Eftersom man kan skrive et PHP script, kalde det .txt og dermed undgå
at det bliver parset tror jeg ikke du har ret. For at den bliver
parset skal du bede Apache om enten at parse denne bestemte fil eller
generelt at parse .txt

--
Henrik Stidsen - http://hs235.dk/ - http://såkadulæredet.dk/
"Is everyone else in the world a moron, or is it just me?"
(Dilbert Newsletter)

---

On Thu, 08 Jul 2004 12:18:59 +0200, Michael Rasmussen <mir@miras.org>
wrote:

>Læg så yderligere hertil, at
>hvis man benytter en processorbaseret webserver, er overhead ved skabelsen
>af en ny proces betydelig - relativt set, hvorfor hastigheden her vil
>blive ramt ekstra hårdt.

Eh, nu misforstår du vist noget. Hvis man springer ud og ind af PHP
igen undervejs, så afvikles PHP ikke to gange.

Som andre nævner, er forskellen virkelig marginal i praksis. Et ekstra
databaseopslag eller lidt fil-access i løbet af scriptet, og resten
vil være vitterligt marginalt.

Selvom benchmarks viser, at det ene skulle være "dobbelt så hurtigt"
eller "ti gange så hurtigt" som det andet, så har det stadigvæk
virkelig marginal betydning i praksis, også på store sites (netop
fordi store sites har tendens til at lave andet end bare at print'e et
par milliarder linjer ud).

--
- Peter Brodersen

Ugens sprogtip: én (og ikke een)

---

On Thu, 08 Jul 2004 13:25:06 +0200, Peter Brodersen wrote:

> On Thu, 08 Jul 2004 12:18:59 +0200, Michael Rasmussen <mir@miras.org>
> wrote:
>
>
> Eh, nu misforstår du vist noget. Hvis man springer ud og ind af PHP igen
> undervejs, så afvikles PHP ikke to gange.
>
Det gælder da kun, hvis webserveren kører i et trådbeseret miljø. Så
vidt jeg har forstået det nye design i apache2, kommer den i en
trådbaseret og en processorbaseret version, hvor den processorbaserede er
default.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
No group of professionals meets except to conspire against the public at large.
      -- Mark Twain

---

Michael Rasmussen wrote:
> Det gælder da kun, hvis webserveren kører i et trådbeseret miljø. Så
> vidt jeg har forstået det nye design i apache2, kommer den i en
> trådbaseret og en processorbaseret version, hvor den processorbaserede er
> default.

Uden overhovedet at være inde i hvordan php er hooket ind i apache, så
er du helt rivende gal på den.

det du beskriver er at en side som følgende:
--begynd--
<?php
$a = 'fez';
?>
Nå, men så var der i øvrigt også noget med at
<?php
$b = 'zef';
?>
jaeh, og så må det være godt.
<?php
print "Nåeh ja, glemte lige: ".$a.", ".$b;
?>

--slut--

skulle køre i 3 tråde eller processer... det er da helt helt forkert...
Når en php-side bliver tilgået er der én tråd(se Peter, jeg skrev
én)/proces af apache(med php-modulet loadet i sig) der behandler siden
fra start til slut.

--
Mvh. Nezar Nielsen
http://fez.dk

Ugens vejrtip: spyt aldrig i modvind

---

On Thu, 08 Jul 2004 13:42:41 +0200, Nezar Nielsen wrote:

>
> Uden overhovedet at være inde i hvordan php er hooket ind i apache, så
> er du helt rivende gal på den.
>
>
> skulle køre i 3 tråde eller processer... det er da helt helt forkert...
> Når en php-side bliver tilgået er der én tråd(se Peter, jeg skrev
> én)/proces af apache(med php-modulet loadet i sig) der behandler siden
> fra start til slut.
Korrekt hvis php er loadet som modul i apache, og ikke afvikles som
selvstændig proces.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Q:   What happens when four WASPs find themselves in the same room?
A:   A dinner party.

---

On Thu, 08 Jul 2004 13:52:53 +0200, Michael Rasmussen wrote:

>> skulle køre i 3 tråde eller processer... det er da helt helt forkert...
>> Når en php-side bliver tilgået er der én tråd(se Peter, jeg skrev
>> én)/proces af apache(med php-modulet loadet i sig) der behandler siden
>> fra start til slut.

> Korrekt hvis php er loadet som modul i apache, og ikke afvikles som
> selvstændig proces.

Det er da det samme. PHP starter kun en process. Prøv engang at køre
Nezars eksempel med din PHP fortolker.

--
Christian Jørgensen
http://www.razor.dk

Få kontrol over dine nyhedsbreve: <http://www.ebrev.info>

---

Michael Rasmussen wrote:
> Korrekt hvis php er loadet som modul i apache, og ikke afvikles som
> selvstændig proces.

Hvis der er nogen ude i den store verden der kører php som CGI så er de
altså også selv ude om det.

Men du har stadig ikke ret.

Hvis php kørte som CGI ville der rigtigt nok skulle forkes en ny proces
til behandling af hvert php-request, men ikke til hver fil, php-blok
eller noget andet lignende.

--
Mvh. Nezar Nielsen
http://fez.dk

Ugens madtip: too much chili is never enough

---

Michael Rasmussen wrote:
> On Thu, 08 Jul 2004 13:42:41 +0200, Nezar Nielsen wrote:
>
>>
>> Uden overhovedet at være inde i hvordan php er hooket ind i apache,
>> så er du helt rivende gal på den.
>>
>>
>> skulle køre i 3 tråde eller processer... det er da helt helt
>> forkert... Når en php-side bliver tilgået er der én tråd(se Peter,
>> jeg skrev én)/proces af apache(med php-modulet loadet i sig) der
>> behandler siden fra start til slut.
> Korrekt hvis php er loadet som modul i apache, og ikke afvikles som
> selvstændig proces.
Prøv alt hvad du vil, her kan du få nogle filer som du kan teste med:

http://surl.dk/1s/

Så kan du revurdere din teorier igen bag efter.
--
MVH Dan Molberg
http://beyond.repair.dk/

---

On Thu, 8 Jul 2004 14:49:29 +0200, "Dan Molberg" <beyond@repair.void>
wrote:

>Prøv alt hvad du vil, her kan du få nogle filer som du kan teste med:
>
>http://surl.dk/1s/

Ikke før surl.dk lærer at sende http:// forrest i Location-headeren :)

Altså:
Location: http://beyond.repair.dk/HTMLvsPHPtest.zip
og ikke, som det er nu:
Location: beyond.repair.dk/HTMLvsPHPtest.zip

--
- Peter Brodersen

Ugens sprogtip: én (og ikke een)

---

On Thu, 08 Jul 2004 16:11:07 +0200, Peter Brodersen wrote:

>>Prøv alt hvad du vil, her kan du få nogle filer som du kan teste med:
>>
>>http://surl.dk/1s/
>
> Ikke før surl.dk lærer at sende http:// forrest i Location-headeren :)
>
> Altså:
> Location: http://beyond.repair.dk/HTMLvsPHPtest.zip
> og ikke, som det er nu:
> Location: beyond.repair.dk/HTMLvsPHPtest.zip

Nu da Peter er så beskeden at han ikke vil gøre det, vil jeg da tillade
mig at anbefale følgende service i stedet:

http://shor.ter.dk

--
Christian Jørgensen
http://www.razor.dk

Få kontrol over dine nyhedsbreve: <http://www.ebrev.info>

---

Peter Brodersen wrote:
> On Thu, 8 Jul 2004 14:49:29 +0200, "Dan Molberg" <beyond@repair.void>
> wrote:
>
>> Prøv alt hvad du vil, her kan du få nogle filer som du kan teste med:
>>
>> http://surl.dk/1s/
>
> Ikke før surl.dk lærer at sende http:// forrest i Location-headeren :)
>
> Altså:
> Location: http://beyond.repair.dk/HTMLvsPHPtest.zip
> og ikke, som det er nu:
> Location: beyond.repair.dk/HTMLvsPHPtest.zip
Det er da ikke surls opgave....

--
MVH Dan Molberg
http://beyond.repair.dk/

---

On Thu, 8 Jul 2004 16:53:41 +0200, "Dan Molberg" <beyond@repair.void>
wrote:

>>> Prøv alt hvad du vil, her kan du få nogle filer som du kan teste med:
>>>
>>> http://surl.dk/1s/
>> Ikke før surl.dk lærer at sende http:// forrest i Location-headeren :)
>Det er da ikke surls opgave....

Ikke hvis surl antager at det er sandsynligt, at folk vil lave
relative stier under surl.dk. Under alle omstændigheder sendte surl.dk
en ugyldig Location-header i det tilfælde.

--
- Peter Brodersen

Ugens sprogtip: én (og ikke een)

---

Peter Brodersen wrote:
> On Thu, 8 Jul 2004 16:53:41 +0200, "Dan Molberg" <beyond@repair.void>
> wrote:
>
>>>> Prøv alt hvad du vil, her kan du få nogle filer som du kan teste
>>>> med:
>>>>
>>>> http://surl.dk/1s/
>>> Ikke før surl.dk lærer at sende http:// forrest i Location-headeren
>>> :)
>> Det er da ikke surls opgave....
>
> Ikke hvis surl antager at det er sandsynligt, at folk vil lave
> relative stier under surl.dk. Under alle omstændigheder sendte surl.dk
> en ugyldig Location-header i det tilfælde.
Har en hevenandhell\c$ den skal de have lov til at lave.... det skal ikke
være http://hevenandhell\c$ så nemt er det.
--
MVH Dan Molberg
http://beyond.repair.dk/

---

On Thu, 8 Jul 2004 17:05:52 +0200, "Dan Molberg" <beyond@repair.void>
wrote:

>Har en hevenandhell\c$ den skal de have lov til at lave....

Det vil næppe virke.

Står man på http://surl.dk/ og får en location til hevenandhell\c$ ,
så kan browseren - hvis den altså ikke ganske enkelt stopper op - kun
betragte det som en relativ URL, og vil derfor prøve
http://surl.dk/hevenandhell\c$

Under alle omstændigheder var dit formål jo stadigvæk ikke at angive
en relativ URL i første omgang. Det er rettet nu, hvilket jo er fint
nok.

>det skal ikke være http://hevenandhell\c$ så nemt er det.

Resultatet bliver stadigvæk bare en relativ URL (for de browsere, der
kompserer for den ugyldige , og ikke hvad, du nok forventer.

RFC2616, 14.10: The field value consists of a single absolute URI.

RFC2396: absoluteURI = scheme ":" ( hier_part | opaque_part )

En adresse i stil med \\servernavn vil dog virke for IE, men det er
stadigvæk ikke en gyldig værdi.

--
- Peter Brodersen

Ugens sprogtip: jf. (og ikke jvf.)

---

On Thu, 08 Jul 2004 13:33:25 +0200, Michael Rasmussen <mir@miras.org>
wrote:

>> Eh, nu misforstår du vist noget. Hvis man springer ud og ind af PHP igen
>> undervejs, så afvikles PHP ikke to gange.
>Det gælder da kun, hvis webserveren kører i et trådbeseret miljø. Så
>vidt jeg har forstået det nye design i apache2, kommer den i en
>trådbaseret og en processorbaseret version, hvor den processorbaserede er
>default.

Nej, der forkes altså ikke en ny php-proces for hver php-starttag
(eller på anden måde afvikles php påny), uanset hvad. Det er samme
php-håndtering, der tager sig af hele inputtet.

Det andet giver jo slet ingen mening. Ellers ville variable,
konstanter, funktions-deklarationer, klasser og så videre jo heller
ikke overleve at man sprang ud og ind af php igen.

Det er tillige ret let at teste:


<?php
$string = "Dette er min string";
print "PID".getmypid();
?>

Test

<?
print $string;
print "PID".getmypid();
?>

--
- Peter Brodersen

Ugens sprogtip: én (og ikke een)

---

On Thu, 08 Jul 2004 12:18:59 +0200, Michael Rasmussen wrote:

>> Forskellen i hastighed er så marginal, at det næsten
>> kommer ud på et.

> Det er ikke en absolut korrekt udtalelse. Som hovedregel, ja, men for
> sites med mange samtidige brugere, eller hvor mængden af behandlede data
> er stor, er det ikke en marginal forskel.

Da PHP lægger sig så tæt op af apache og dermed HTTP protokollen,
og dermed giver et sessions-løst miljø, vil jeg (lettere ignorant)
tillade mig at antage at PHP skalerer nogenlunde lineært. Derfor har det
ikke noget at sige om der er 100 samtidige brugere eller 5 - belastningen
vil være lineært proportionelt.

--
Christian Jørgensen
http://www.razor.dk

Få kontrol over dine nyhedsbreve: <http://www.ebrev.info>

---

[x] wrote:
> Spørgsmålet er så, kan man med sikkerhed sige hvilken løsning der
> er hurtigst ? Er der en tommelfinger regel jeg ikke kender ?
> Eller er det en vurdering fra gang til gang ? Og hvis så, hvad
> tommelfingerregelen ?

well.. hvis man skal tro hvad php.net folkene skriver, så anbefaler de
at du escaper din kode og undlader brugen af echo og print.

- dog abefaler de også enkelt quotes (') istedet for dobbelquotes ("),
men i alle deres eksempler bruger de dobbelquotes.... det kan jo godt
undre en ;)

jeg selv bruger Smarty som template engine, så jeg skriver aldrig et
echo eller print selv... om det er vejen frem for dig ? ja det er et
helt andet spørgsmål...


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : Data for intranet got routed through the extranet
: and landed on the internet.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

Ulrik Nielsen wrote:

>> Spørgsmålet er så, kan man med sikkerhed sige hvilken løsning der
>> er hurtigst ? Er der en tommelfinger regel jeg ikke kender ?
>> Eller er det en vurdering fra gang til gang ? Og hvis så, hvad
>> tommelfingerregelen ?
> well.. hvis man skal tro hvad php.net folkene skriver, så anbefaler de
> at du escaper din kode og undlader brugen af echo og print.

Ja, det ville heller ikke give mening andet. Uden at vide det med
sikkerhed vil jeg skyde på at php er opbygget sådan at noget af det
første compileren den gør er at fjerne alt der ikke er inde i mellem <?
og ?>, erastatte require osv med indholdet af de filer der nu skal
inkluderes.

> - dog abefaler de også enkelt quotes (') istedet for dobbelquotes ("),
> men i alle deres eksempler bruger de dobbelquotes.... det kan jo godt
> undre en ;)

Det giver igen også mening, du kan nemlig ikke skrive variabler inde i
mellem ' og ', altså er der mindre den skal tage sig af :)

> jeg selv bruger Smarty som template engine, så jeg skriver aldrig et
> echo eller print selv... om det er vejen frem for dig ? ja det er et
> helt andet spørgsmål...

Smarty generere ikke ret optimal kode, nu vi alligevel snakker hastighed
- dog kan den cache dens output hvilket er meget effektivt, men intet
er lige så effektivt som en god gammeldags statisk .html fil.

Og så vil jeg også lige påpege at det ved brug af forskellige ting og
sager er muligt at give php nyt liv og dermed kunne skalere bedre på ens
nuværende setup. Bl.a. findes der noget der hedder Turck MMCache[1] som
gemmer den oversatte udgave af ens php script i rammen (eller på disken)
hvilket kan give et ordenligt skub ned ad bakke.

Dette lavede jeg en lille test[2] på engang og har brugt det siden hvor
jeg kan komme til det. Og jeg er endnu ikke blevet skuffet over det :)

[1]: http://turck-mmcache.sourceforge.net/index_old.html
[2]: http://swag.dk/pub/mmcache.txt

--
Mads Sülau Jørgensen
"All glory to the hypno toad!"

---

> > jeg selv bruger Smarty som template engine, så jeg skriver aldrig et
> > echo eller print selv... om det er vejen frem for dig ? ja det er et
> > helt andet spørgsmål...
>
> Smarty generere ikke ret optimal kode, nu vi alligevel snakker hastighed
> - dog kan den cache dens output hvilket er meget effektivt, men intet
> er lige så effektivt som en god gammeldags statisk .html fil.
>
> Og så vil jeg også lige påpege at det ved brug af forskellige ting og
> sager er muligt at give php nyt liv og dermed kunne skalere bedre på ens
> nuværende setup. Bl.a. findes der noget der hedder Turck MMCache[1] som
> gemmer den oversatte udgave af ens php script i rammen (eller på disken)
> hvilket kan give et ordenligt skub ned ad bakke.

Men hvor effektivt er det at cache sine sider, hvis meget indhold er
dynamisk genereret fra en database? Eksempelvis fremsøgte brugere el.
lign...?

Jeg har aldrig selv anvendt Smarty's caching særlig optimalt (bruger selv
Smarty), for de fleste af mine sider er dynamiske udfra en database. Findes
der en smart metode her? Fx. en særlig måde at inkludere sider eller php på?

Mvh.
Thomas Rokamp

---

Thomas Rokamp wrote:
> Men hvor effektivt er det at cache sine sider, hvis meget indhold er
> dynamisk genereret fra en database? Eksempelvis fremsøgte brugere el.
> lign...?

Forbindelsen og hentningen fra databasen skal selvfølgelig stadig laves,
men hele jobbet med at fortolke alt php'en, det er gjort i forvejen, så
det bare skal køres.

--
Mvh. Nezar Nielsen
http://fez.dk

---

Thomas Rokamp wrote:
> Jeg har aldrig selv anvendt Smarty's caching særlig optimalt (bruger selv
> Smarty), for de fleste af mine sider er dynamiske udfra en database. Findes
> der en smart metode her? Fx. en særlig måde at inkludere sider eller php på?
>

jeg bruger caching i Smarty selvom jeg har dynamisk genereret indhold,
- det er nemlig muligt at "splitte" sine sider op i indhold man vil ha
cachet og indhold man ikke vil.
det lyder måske temmelig åndsvagt, men det funker ret godt.

hos mig kunne et ex. være at det eneste der ændre sig på en side er
antallet af "live users", ja så cashes hele siden pånær den variabel der
indeholder antallet af "live users".

- det sagt så kan man også sætte cache tiden ned til ex. 5-10 sec, det
vil for de fleste føles som "live data" men på et stærkt trafikkeret
site er det en det der spares for webserveren :)


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : Data for intranet got routed through the extranet
: and landed on the internet.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

Thomas Rokamp wrote:

>>[snip]
> Men hvor effektivt er det at cache sine sider, hvis meget indhold er
> dynamisk genereret fra en database? Eksempelvis fremsøgte brugere el.
> lign...?

Det er _meget_ effektivt hvis lavet rigtigt. Man kunne eks. bruge
PEAR_Cache til at cache resultatet fra sine SQL kald, udregninger osv osv.

> Jeg har aldrig selv anvendt Smarty's caching særlig optimalt (bruger selv
> Smarty), for de fleste af mine sider er dynamiske udfra en database. Findes
> der en smart metode her? Fx. en særlig måde at inkludere sider eller php på?

Mener du at du sætter tekst ind fra et CMS eller at du har dynamiske
elementer på din side?

Tricket mht. caching er jo blot ikke at opdatere sit content før der
sker en ændring i det, sådan kort fortalt :) - fx. at generere statiske
filer i stedet for at hente teksten ud af databasen og printe den ud ved
hvert request.

--
Mads Sülau Jørgensen
"All glory to the hypno toad!"

---

Tak til jer alle for jeres input. Om jeg er blevet klogere på vedr.
dette ved jeg ikke, men er dog nået til den konklusion at jeg vælger den
løsning der i den givne sutiation er lettest.

Endnu engang tak.

--
mvh. [x] - www.ionline.dk