Onderwerp: [PHP] statische gegevens globaal in geheugen houden

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

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?

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

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

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

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

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

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/

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

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

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

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/developerwork.../j-pj2ee6.html
http://www.microsoft.com/windows2000...sp/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

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

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.

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