---

Hver unik bruger har en håndfuld variabler (personal settings).

Hvad er hurtigst: Database look-up (MySQL) for hver side der serves
eller include en fil med variablerne ?

--
Bjarne Jensen

---

---

Anders K. Madsen wrote:
>>Hvad er hurtigst: Database look-up (MySQL) for hver side der serves
>>eller include en fil med variablerne ?
>>
>
> Sessions...
> http://php.net/session

sessions behøver ikke være hurtigere end en include... sessions gemmes i
enten; fil, database eller "shared memory", hvis sessions køre via sm,
ja så er det ret sikkert hurtigere, ellers er det jo afhængig af
filsystem eller database ... :)

dog er det jo bare at lave en lille test...


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : The electrician didn't know what the yellow cable
: was so he yanked the ethernet out.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

---

Anders K. Madsen wrote:
>>sessions behøver ikke være hurtigere end en include... sessions gemmes
>>i enten; fil, database eller "shared memory", hvis sessions køre via
>>sm, ja så er det ret sikkert hurtigere, ellers er det jo afhængig af
>>filsystem eller database ... :)
>
>
> True.
> Jeg burde måske også have skrevet at sessions er beregnet til den slags
> ting og derfor ofte vil være at foretrække... Det er jo også meget meget
> lettere at håndtere på kode-niveau. Med en fil, skal man åbne, skrive og
> lukke, og læse. Med en db, skal der laves opslag o.s.v.
> Sessions er bare at bruge dem. :)

jeg er helt enig.. er vidst bare lidt pedantisk idag ;)

- ud over det så er det anbefalelses værdigt at flytte
sessionhåndteringen fra filsystem til database, hvis man da har mulighed
for det...
- database er hurtigere end filsystem hvad sessions angår, samt det er
en mere "sikker" løsning.


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : The electrician didn't know what the yellow cable
: was so he yanked the ethernet out.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

Ulrik Nielsen <un.spam@tiscali.dk> writes:

> - database er hurtigere end filsystem hvad sessions angår, samt det er
> en mere "sikker" løsning.

Har du nogen konkrete benchmarks til at bakke den påstand op? Jeg
vil rent logisk tro, at det forholder sig omvendt.

--
Med venlig hilsen
- Jacob Atzen

---

---

"Anders K. Madsen" <madsen@lillesvin.linux.dk> writes:

> > Har du nogen konkrete benchmarks til at bakke den påstand op? Jeg
> > vil rent logisk tro, at det forholder sig omvendt.
>
> Måske, men det er nu sådan at der ikke skal ret meget data til før
> filsystemet bliver for langsomt at lege med...

Hvor tror du databasen henter sine data fra? Jeg kan virkelig ikke se,
hvorfor det skulle være hurtigere at læse tekst fra en database end
fra en fil.

--
Med venlig hilsen
- Jacob Atzen

---

---

"Anders K. Madsen" <madsen@lillesvin.linux.dk> writes:

> Måske ikke, men det er der andre der kan...
> Prøv selv at sniffe lidt rundt på google.

Jeg har googlet og ikke fundet noget interessant.

Har du et par links til nogen sider, der underbygger påstanden?

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
>>Måske ikke, men det er der andre der kan...
>>Prøv selv at sniffe lidt rundt på google.
>
> Jeg har googlet og ikke fundet noget interessant.
>
> Har du et par links til nogen sider, der underbygger påstanden?

har lige googlet et par stykker..:

http://revjim.net/item/9489/
http://www.eng.mu.edu/corlissg/168Search.03F/n_files_vs_db.html


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : The Token fell out of the ring. Call us when you
: find it.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

On Wed, 21 Jul 2004 09:39:25 +0200, Ulrik Nielsen <un.spam@tiscali.dk>
wrote:

>har lige googlet et par stykker..:
>
>http://revjim.net/item/9489/
>http://www.eng.mu.edu/corlissg/168Search.03F/n_files_vs_db.html

Det er ikke sammenligneligt, i forhold til den aktuelle sag. Vi kender
filnavnet på forhånd, og tilgår det direkte, og skal have hele
indholdet.

Artiklerne nævner tilfælde, hvor man skal søge et kæmpestort katalog
igennem efter en fil, eller kun har brug for en lille del af en stor
fil, men bliver nødt til at scanne den igennem. Her giver det
selvfølgelig mening at gøre brug af en database.

Men angående sessions på fil-niveau, så skal vi ikke lede efter filen
(vi forsøger at tilgå sess_(session-id'et) i session.safe_path), og vi
antager, at vi alligevel skal unserialize al indholdet.

Derimod kan der være andre tilfælde, hvor en database er mere
hensigtsmæssig. Hvis det er persistent brugerdata, han vil gemme, kan
en database være mere hensigtsmæssig (mindre risiko for usammenhæng
mellem indhold i database og filer, ingen mapper skal være writable
for apaches bruger). Under alle omstændigheder tvivler jeg på, at der
vil være den store, endelige forskel ved et sådan hyggeprojekt. Det er
hurtigt at tilgå en fil med lidt indhold direkte, og det er hurtigt at
tilgå en indekseret række i en database.

Hvis derimod absolut vil superoptimere, så kunne man overveje
MEMORY(HEAP)-tabeller (for en database-løsning), eller shared
memory-funktioner (shmop, for en php-løsning). Dog afhænger det igen
om data skal overleve en nedlukning.


Dog er der andre grunde til at være bekymret over en
standard-session-opsætning:
http://stock.ter.dk/session.php
http://stock.ter.dk/phpdev.php

Jeg er om ikke andet holdt op med at anbefale PHP til nye
administratorer, som tingene ser ud i øjeblikket.

--
- Peter Brodersen

Ugens sprogtip: alle sammen (og ikke allesammen)

---

Ulrik Nielsen <un.spam@tiscali.dk> writes:

> Jacob Atzen wrote:
> >>Måske ikke, men det er der andre der kan...
> >>Prøv selv at sniffe lidt rundt på google.
> > Jeg har googlet og ikke fundet noget interessant.
> > Har du et par links til nogen sider, der underbygger påstanden?
>
> har lige googlet et par stykker..:

Udover det Peter Brodersen allerede har svaret vil jeg lige tilføje...

> http://revjim.net/item/9489/

Som jo illustrerer min pointe ganske fint: Hvis du kigger under "Get
one item" som jo er vores aktuelle tilfælde ser du at

Filsystem gennemsnitstid: 0.000182
Database gennemsnitstid: 0.001735

Filsystemet er altså i gennemsnit 10 gange hurtigere end databasen til
at "Get one item". Hvad der så menes med "Get one item" er lidt
uklart, men jeg går ud fra det kan oversættes til at "læse indholdet
af en post".

> http://www.eng.mu.edu/corlissg/168Search.03F/n_files_vs_db.html

Jeg kan ikke finde noget på den side, der har noget med det aktuelle
tilfælde at gøre. Under "Fast or slow?" står der kun noget om
searching og indexing - ingen af delene er aktuelle i vores tilfælde.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> Jeg kan ikke finde noget på den side, der har noget med det aktuelle
> tilfælde at gøre. Under "Fast or slow?" står der kun noget om
> searching og indexing - ingen af delene er aktuelle i vores tilfælde.


nå, jeg besluttede mig til at hvis jeg skulle ta fejl, så skulle det
gøres ordentligt....

jeg har lavet en test der kun skriver session data til enten fil eller
database, og så checker hvor hvor lang tid det tog.

og ja jeg tog fejl.
- der er dog ikke noget jeg hadere mere end at tro jeg har ret når jeg
er sikker på at jeg et eller andet sted har læst andet...

se evt: http://test.argh.dk/session/

- så øv du havde ret og jeg tog fejl :)


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : Zombie processes detected, machine is haunted.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/

---

Ulrik Nielsen <un.spam@tiscali.dk> writes:

> - så øv du havde ret og jeg tog fejl :)

Og du er mand nok til at indrømme det. Karmapoint for det

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> Ulrik Nielsen <un.spam@tiscali.dk> writes:
>>- så øv du havde ret og jeg tog fejl :)
>
> Og du er mand nok til at indrømme det. Karmapoint for det

takker :) og vi skal begge slukke puteren og lave noget mere
fornuftigt..... *lol*


--
ulrik nielsen
----------------------------------------------------------------------
excuse of the day : Zombie processes detected, machine is haunted.
from bofh : http://www.cs.wisc.edu/~ballard/bofh/