[PHP] statische gegevens globaal in geheugen houden

Rene Pijlman wrote:

> John Bokma:
>>Rene Pijlman:
>>> Waarom verzint iedereen hier toch de meest vreselijke constructies
>>> om toch vooral maar niets in het geheugen te hoeven houden? Ik
>>> betaal verdorie voor 1.024 MByte RAM, dan wil ik dat ook gebruiken,
>>> ja?
>>
>>Zet de bestandjes in een ramdisk :-) Verder gok ik dat een beetje OS
>>tegenwoordig veel gebruikte bestanden gewoon in het geheugen cache't,
>>als er voldoende is.
>
> Ik wil het voor maximale efficiëntie gebruiken, had ik erbij moeten
> zeggen.

Het vinden van die oplossing brengt maximale kosten met zich mee,
kortom, meestal niet rendabel. Verder spelen allerlei factoren mee waar
je geen controle over hebt.

Als je de bestandjes voldoende klein maakt lijkt mij de overhead
minimaal (het opzoeken van de juiste key). Als je de bestandjes fixed
records geeft en binary search toepast op de key hmmm... wellicht zelfs
trager :-). Een bestandje van 1K inlezen, en daar een regeltje uitvissen
gaat voldoende snel, lijkt mij.

Zoals ik al schreef, OSen doen tegenwoordig aan nogal wat caching op
diverse nivo's. Het kan heel goed zijn dat als je die ramdisk truuk
doet, je nauwelijks verschil meet. Idem voor shared memory.

Ik heb geen idee hoe je URLs er uit zien, en hoe je wilt redirecten (ik
gok dat het iets als foo/bar?id=616 naar /keyword1/keyword2/keyword3
moet worden). En geen idee hoe vaak dat gebeurd (ik gok/hoop dat je
interne links al netjes staan, etc.).

--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html

John Bokma:
>Rene Pijlman:
>> Ik wil het voor maximale efficiëntie gebruiken, had ik erbij moeten
>> zeggen.
>
>Het vinden van die oplossing brengt maximale kosten met zich mee,
>kortom, meestal niet rendabel.

De efficiëntste oplossing is niet per se goedkoper dan een minder
efficiënte kludge met bestanden, ramdisks en wat al niet. Maar ik ben met
je eens dat zakelijke optimalisatie een grens stelt aan technische
optimalisatie.

>Het kan heel goed zijn dat als je die ramdisk truuk doet, je nauwelijks
>verschil meet. Idem voor shared memory.

Nou, de shared-memory oplossing bepaalt de URL zonder userland/kernelmode
context switch. Dat was altijd meetbaar sneller dan andere oplossingen met
zulke switches, is mijn ervaring van jaren geleden met SunOS. Maar de
memcached-oplossing heeft deze eigenschap niet, die zou inderdaad weleens
weinig verschil kunnen maken.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

> Hoe doe ik dat het beste?

De data in een enviroment variabele zetten of een memory disk, maar als je
idd een php bestand include komt die vanzelf in de cache bij zowel linux op
filesystem niveau als bij php.

Kijk ook eens naar de proxy functie, dan cache je php indien bv de
parameters van GET niet aangepast zijn. Dan moet je wel duidelijk
onderscheid maken en geen GET gebruiken voor meer dan het ophalen van
gegevens, POST is dan voor mutaties/acties in je website.

Maar ipv heel veel tijd te besteden -> koop snellere server ;-) Ik koop elk
jaar nieuwe, de ouden worden werkstations op kantoor en die oudere worden
bonusje of voor goed doel.