[PHP] statische gegevens globaal in geheugen houden

[Rene Pijlman]

Ik heb een kleine hoeveelheid min of meer statische gegevens (+- 1 MB)
nodig in een eenvoudige sessieloze PHP-applicatie. Ik zou die eenmaal
vanuit een tekstfile in geheugen willen lezen om ze met minimale overhead
overal in de applicatie te kunnen gebruiken. Hoe doe ik dat het beste?

Per Apache proces inlezen in global memory? Shared memory? memcached?

Platform: Linux 2.4, Apache 1.3, PHP 4.1.

Het moet natuurlijk t.z.t. met Apache 2 (threading) ook werken.

--
René Pijlman

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

[Daniel Tryba]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
> Ik heb een kleine hoeveelheid min of meer statische gegevens (+- 1 MB)
> nodig in een eenvoudige sessieloze PHP-applicatie. Ik zou die eenmaal
> vanuit een tekstfile in geheugen willen lezen om ze met minimale overhead
> overal in de applicatie te kunnen gebruiken. Hoe doe ik dat het beste?

Als ik dit lees krijg ik het vermoeden dat hier sprake is van een
voortijdige poging tot optimalisatie. Is het lezen van een file van disk
(wordt dan gecached door het OS in de diskcache (eventueel icm met een
accelerator/compiler)) werkelijke de bottleneck?

Aangezien de data min of meer statisch is lijkt mij persoonlijk de
diskcache (of de cache van je RDMBS) voldoende, echter wat zijn de
voorwaarden in het geval een update, bv moeten alle "threads" blokken
totdat de data geupdate is?

[Rene Pijlman]

Daniel Tryba:
>Rene Pijlman:
>> Ik heb een kleine hoeveelheid min of meer statische gegevens (+- 1 MB)
>> nodig in een eenvoudige sessieloze PHP-applicatie. Ik zou die eenmaal
>> vanuit een tekstfile in geheugen willen lezen om ze met minimale overhead
>> overal in de applicatie te kunnen gebruiken. Hoe doe ik dat het beste?
>
>Als ik dit lees krijg ik het vermoeden dat hier sprake is van een
>voortijdige poging tot optimalisatie.

Ha, hier zou ik uren over kunnen praten.

Aan de ene kant heb je gelijk, programmeurs richten zich vaak op basis van
misplaatste aannames op allerlei zinloze optimalisaties, in plaats van
eerst te bouwen, dan te meten en de werkelijke tijdvreters aan te pakken.

Maar aan de andere kant vind ik het onzin om iets eerst te bouwen, en
daarna pas over de architectuur na te denken.

>Is het lezen van een file van disk (wordt dan gecached door het OS in de
>diskcache (eventueel icm met een accelerator/compiler)) werkelijke de
>bottleneck?

Ja, dat denk ik wel. Het gaat om een database met enkele duizenden
redirect-URLs. Het script moet niets anders doen dan een parameter uit de
URL halen, op basis daarvan de redirect-URL bepalen, een logentry
schrijven en een location-header terugsturen. Mijn gezond verstand zegt
dat het niet handig is om in dat geval bij elke hit 1 MB data in te lezen,
te parsen en te hashen.

>Aangezien de data min of meer statisch is lijkt mij persoonlijk de
>diskcache (of de cache van je RDMBS) voldoende

Mnja, maar het lijkt me toch optimaler om het in gestructureerde vorm in
geheugen te houden en wat is daar nu eigenlijk op tegen?

>echter wat zijn de voorwaarden in het geval een update, bv moeten alle
>"threads" blokken totdat de data geupdate is?

Er zijn in mijn geval praktisch geen updates. Zelfs Apache herstarten na
een update zou aanvaardbaar zijn.

Ik overweeg om de data in de vorm van PHP-code te schrijven (initialisatie
van een constante hash table, die dan natuurlijk in elk Apache/PHP-proces
gerepliceerd wordt). Zou zo'n hash table met een PHP accelerator (zoals
Turcks's MMcache of eAccelerator) in geïnitialiseerde vorm gecached
worden, of zou die per scipt-executie telkens opnieuw geïnitialiseerd
worden?

Ik heb nog wat zitten Googlen, maar je moet zoiets anders toch zelf gaan
fabrieken met SysV shared memory (mjammie) of iets als memcached.

--
René Pijlman

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

[Daniel Tryba]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Is het lezen van een file van disk (wordt dan gecached door het OS in de
>>diskcache (eventueel icm met een accelerator/compiler)) werkelijke de
>>bottleneck?
>
> Ja, dat denk ik wel. Het gaat om een database met enkele duizenden
> redirect-URLs. Het script moet niets anders doen dan een parameter uit de
> URL halen, op basis daarvan de redirect-URL bepalen, een logentry
> schrijven en een location-header terugsturen. Mijn gezond verstand zegt
> dat het niet handig is om in dat geval bij elke hit 1 MB data in te lezen,
> te parsen en te hashen.

Als ik dit zo lees is het cachen van die data een poging tot mogelijke
symptoom bestrijding.

>>Aangezien de data min of meer statisch is lijkt mij persoonlijk de
>>diskcache (of de cache van je RDMBS) voldoende
>
> Mnja, maar het lijkt me toch optimaler om het in gestructureerde vorm in
> geheugen te houden en wat is daar nu eigenlijk op tegen?

Niets, maar domweg die data cachen lijkt me dan niet wat je zoekt.

>>echter wat zijn de voorwaarden in het geval een update, bv moeten alle
>>"threads" blokken totdat de data geupdate is?
>
> Er zijn in mijn geval praktisch geen updates. Zelfs Apache herstarten na
> een update zou aanvaardbaar zijn.
>
> Ik overweeg om de data in de vorm van PHP-code te schrijven (initialisatie
> van een constante hash table, die dan natuurlijk in elk Apache/PHP-proces
> gerepliceerd wordt). Zou zo'n hash table met een PHP accelerator (zoals
> Turcks's MMcache of eAccelerator) in ge?nitialiseerde vorm gecached
> worden, of zou die per scipt-executie telkens opnieuw ge?nitialiseerd
> worden?

Ik mag toch hopen dat het script in een geinitializeerde vorm wordt
gecached ("eAccelerator ... increases performance of PHP scripts by
caching them in compiled state, so that the overhead of compiling is
almost completely eliminated."), het include()-en van een object/hash
zou daarmee dus een snelle manier van cachen zijn.

> Ik heb nog wat zitten Googlen, maar je moet zoiets anders toch zelf gaan
> fabrieken met SysV shared memory (mjammie) of iets als memcached.

Zonder gehinderd te worden over mijn gebrek aan kennis omtrend jou data
en de bewerkingen die je daarop wilt uitvoeren zou ik een externe daemon
gebruiken die de data dus in memory houdt en de queries uitvoert. Aan te
roepen via een php class. Lekker abstract zodat je minimaal kan beginnen
(simpel elke keer includen bij aanroep script) en makkelijk kan
uitbreiden tot een zinnige query/resultaat cache (iets waar memcached
wel geschikt voor lijkt te zijn mits je het kan gebruiken als een
"readonly" persisten hash).

[John Bokma]

Rene Pijlman wrote:

> Ja, dat denk ik wel. Het gaat om een database met enkele duizenden
> redirect-URLs. Het script moet niets anders doen dan een parameter uit
> de URL halen, op basis daarvan de redirect-URL bepalen, een logentry
> schrijven en een location-header terugsturen. Mijn gezond verstand
> zegt dat het niet handig is om in dat geval bij elke hit 1 MB data in
> te lezen, te parsen en te hashen.

lees parameter
bepaal een hash code van n bits (je zou b.v. een MD5 digest kunnen
berekenen over de hash code)
lees bestand in met naam hex representatie van n bits
etc.

ik zou testen met 8 bits => 4096 bestandjes, elk ca. 4K.

Als je het onderste uit de kan wilt, een C module in Apache hangen.

--
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

[Rene Pijlman]

John Bokma:
>Rene Pijlman:
>> Ja, dat denk ik wel. Het gaat om een database met enkele duizenden
>> redirect-URLs. Het script moet niets anders doen dan een parameter uit
>> de URL halen, op basis daarvan de redirect-URL bepalen, een logentry
>> schrijven en een location-header terugsturen. Mijn gezond verstand
>> zegt dat het niet handig is om in dat geval bij elke hit 1 MB data in
>> te lezen, te parsen en te hashen.
>
>lees parameter
>bepaal een hash code van n bits (je zou b.v. een MD5 digest kunnen
>berekenen over de hash code)

Tot zover geheel mee eens.

>lees bestand in met naam hex representatie van n bits

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?

>Als je het onderste uit de kan wilt, een C module in Apache hangen.

Idd.

--
René Pijlman

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

[Rene Pijlman]

Daniel Tryba:
>Als ik dit zo lees is het cachen van die data een poging tot mogelijke
>symptoom bestrijding.

Ik ben reuze benieuwd naar wat je hierover te zeggen hebt.

--
René Pijlman

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

[Jan Ehrhardt]

Rene Pijlman in nl.internet.www.server-side (Thu, 12 May 2005 01:51:35
+0200):

>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?

Misschien omdat we niet begrijpen wat je eigenlijke probleem is. Schrijf
die gegevens gewoon als PHP-script, include dat script waar nodig en
laat het cachen over aan je PHP accelerator. Met een kwart MB, maar dan
zonder accelerator doe ik dat ook. Geen centje pijn.

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

[John Bokma]

Rene Pijlman wrote:

> 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.


--
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

[Daniel Tryba]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Als ik dit zo lees is het cachen van die data een poging tot mogelijke
>>symptoom bestrijding.
>
> Ik ben reuze benieuwd naar wat je hierover te zeggen hebt.

Stond in de laatste paragraaf: "zinnig query/resultaat cache".

[Rene Pijlman]

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.

--
René Pijlman

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

[Rene Pijlman]

Jan Ehrhardt:
>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?
>
>Misschien omdat we niet begrijpen wat je eigenlijke probleem is.

Da's gek, want het is een vrij alledaagse programmeerwens: een berekend
resultaat - dat niet verandert en per request nodig is in alle requests
van een applicatie - in geheugen houden, om het niet per webrequest
telkens opnieuw te I/O-en en/of te berekenen.

In de wereld van Java en ASP (application scope) is dat wat makkelijker
dan in PHP, waar je het zelf met shared memory of memcached moet
knutselen.
http://www-106.ibm.com/developerworks/java/library/j-pj2ee6.html
http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/asp/iiwavar.htm

>Schrijf die gegevens gewoon als PHP-script, include dat script waar nodig en
>laat het cachen over aan je PHP accelerator. Met een kwart MB, maar dan
>zonder accelerator doe ik dat ook. Geen centje pijn.

Tuurlijk, in de PHP-wereld is er altijd wel een padvindersvoorbeeld te
vinden waarbij een willekeurig inefficiënte oplossing voldoet :-)

--
René Pijlman

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

[Rene Pijlman]

Daniel Tryba:
>Rene Pijlman:
>>>Als ik dit zo lees is het cachen van die data een poging tot mogelijke
>>>symptoom bestrijding.
>>
>> Ik ben reuze benieuwd naar wat je hierover te zeggen hebt.
>
>Stond in de laatste paragraaf: "zinnig query/resultaat cache".

Het spijt me, ik kan je niet volgen. Wat bedoel je toch met dat
"symptoom"?

--
René Pijlman

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

[Daniel Tryba]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Stond in de laatste paragraaf: "zinnig query/resultaat cache".
>
> Het spijt me, ik kan je niet volgen. Wat bedoel je toch met dat
> "symptoom"?

Het gebrek aan een zinnige query/resultaat cache, maar ui een reactie op
Jan is het nu ook pas duidelijk dat dit schijnbaar is wat je zoekt itt
het cachen van de input data waaruit een resultaat kan worden
gedistileert. Ik betuig dan ook oprecht mijn spijt voor alle verwaring
die ik ben doen onstaan naar aanleiding van mijn interpretatie van de
OP.

Maar goed, als je de moeite neemt om even naar memcached te kijken zal
je zien dat die het makkelijk mogelijk maakt om een hash in geheugen te
houden.

[Rene Pijlman]

Daniel Tryba:
>Maar goed, als je de moeite neemt om even naar memcached te kijken zal
>je zien dat die het makkelijk mogelijk maakt om een hash in geheugen te
>houden.

Dat lijkt me inderdaad de aangewezen weg. Dankjewel voor het meedenken.

--
René Pijlman

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

[John Bokma]

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

[Rene Pijlman]

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

[Sturkie]

> 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.