[PHP] Variabele voor alle bezoekers tegelijk

[Pogostokje]

Ik zit met een uitdaging voor een PHP gebaseerde website. Wat ik wil is dat er op basis van een "beheerhandeling" (iets wat gebeurd op een afgeschermd stukje site, denk aan een knopje of een veldje) bij alle bezoekers als ze over de site gaan een bepaalde korte tekst wordt getoond. Het wel of niet tonen moet dus centraal aan en uitgezet kunnen worden. De tekst is overal gelijk. Het aanzetten zal sporadisch gebeuren, in 99% van de tijd is er dus geen tekst te tonen. Denk hierbij aan een storingsmelding bijvoorbeeld. De overhead moet dus minimaal zijn want het wordt maar zelden gebruikt.

De uitdaging die ik hier heb is dat ik niet voor elke pagina die wordt opgevraagd een extra database lookup wil doen om te bepalen of er iets getoond moet worden. Met het aantal bezoekers is dat niet verstandig. Om dezelfde reden wil ik ook liever geen file op de server moeten inlezen.
De site gebruikt al sessies, waarin onder andere wat relevante info van de bezoeker wordt bijgehouden wat op elke pagina terugkomt. Dit zou een perfecte plek zijn om indien nodig die tekst te plaatsen en daar dan op te checken maar een sessie is voor zover ik kan zien strict "persoonlijk".

Uit een ver verleden weet ik dat dit met ASP wel mogelijk is, je kunt daar een soort applicatie variabele zetten die voor alle bezoekers gelden. Ik kan dit in de PHP manuals echter niet terugvinden, wat daar "global session" genoemd wordt is de hele sessie ... maar wel van een enkele gebruiker. Helaas dus, dat spoor loopt dood.

Wat is nou een slim truukje om wat ik wil te doen? Ik kan uiteindelijk altijd nog naar de database-oplossing toe, maar ja, server resources zijn ook eindig.

[spone]

Misschien zou je met PHP een environment variable kunnen zetten die vervolgens wordt uitgelezen.

Of de in te voegen tekst in een bestandje zetten en deze uitlezen afhankelijk van een file_exists instructie? Lijkt me ook niet heel erg kostbaar qua resources.

Zo even 2 mogelijkheden die door mn hoofd schieten

edit: of gebruik maken van een shared memory block: http://php.net/manual/en/ref.shmop.php

[ Voor 12% gewijzigd door spone op 03-02-2012 21:21 ]

[ValHallASW]

Pogostokje schreef op vrijdag 03 februari 2012 @ 21:16:
De uitdaging die ik hier heb is dat ik niet voor elke pagina die wordt opgevraagd een extra database lookup wil doen om te bepalen of er iets getoond moet worden. Met het aantal bezoekers is dat niet verstandig. Om dezelfde reden wil ik ook liever geen file op de server moeten inlezen.

Hoewel ik denk dat je punt over 'te zwaar voor een database' nonsens is (Wikipedia doet het ook, en heeft er voor zover ik weer meer dan één database-lookup voor nodig) - je punt over een file inlezen is helemaal BS. Je léést al PHP-files in, en een extra include, file read of whatever is echt geen enkel probleem.

In andere woorden: je zet twee dingen weg als 'niet verstandig' zonder dat je enige data hebt over hoe problematisch ze eigenlijk zijn. Implementeer eerst eens wat, en ga eventueel dán nog eens kijken of je het moet optimaliseren door te cachen (wat ook niet meer is dan een bestand op een schijf wegschrijven/inlezen).

[SeatRider]

Ja. En anders maak je 2 versies van je pagina('s), eentje die de extra tekst laadt, en eentje zonder die functie.

[Pogostokje]

Goeie tips. Misschien denk ik er te moeilijk over. Het is goed om weer even met je hoofd uit de wolken gehaald te worden.
In mijn verdediging, de backend database is redelijk zwaar belast (in verhouding tot de servers) en de site maakt al gebruik van caches waar mogelijk. Om die reden ben ik misschien wat te voorzichtig om daar toch weer dynamische info in te plaatsen. Ik ga het gewoon eens proberen.

[YopY]

Dan maak je het toch niet dynamisch? Gewoon een edit in je template maken (of wat dan ook) met daarin het bericht; 0 extra overhead, als je je daar heel veel zorgen over maakt, en het is ook nog eens de meest eenvoudige oplossing.

[NMe]

Pogostokje schreef op vrijdag 03 februari 2012 @ 21:35:
Goeie tips. Misschien denk ik er te moeilijk over. Het is goed om weer even met je hoofd uit de wolken gehaald te worden.
In mijn verdediging, de backend database is redelijk zwaar belast (in verhouding tot de servers) en de site maakt al gebruik van caches waar mogelijk. Om die reden ben ik misschien wat te voorzichtig om daar toch weer dynamische info in te plaatsen. Ik ga het gewoon eens proberen.

Ik denk dat je onderschat wat een database snel kan doen. Dit soort simpele query's zouden geen probleem moeten zijn voor je systeem, juist omdat die bij elke pageview voorbij komt. De query blijft dan gewoon in je cache zitten en het resultaat is er zowat instant.

[GlowMouse]

NMe schreef op vrijdag 03 februari 2012 @ 22:16:
[...]

Ik denk dat je onderschat wat een database snel kan doen. Dit soort simpele query's zouden geen probleem moeten zijn voor je systeem, juist omdat die bij elke pageview voorbij komt. De query blijft dan gewoon in je cache zitten en het resultaat is er zowat instant.

Die cache staat juist uit bij een beetje server. Dan nog is dit het soort query waar je een gigabitlijn mee voltrekt.

[Cartman!]

Maak gewoon 1 file die je altijd include, op het moment dat de status wijzigt van je bericht (wel, geen of andere tekst) dan genereer je die include opnieuw. Simpele cache dus.

[NMe]

GlowMouse schreef op zaterdag 04 februari 2012 @ 00:11:
[...]

Die cache staat juist uit bij een beetje server. Dan nog is dit het soort query waar je een gigabitlijn mee voltrekt.

Wat, een query als "SELECT Value FROM Setting WHERE SettingName = 'Maitenance Mode'"? Zo'n statische query in een table met minder dan honderd records doet het zelfs zonder query cache uitermate snel. En waarom zou de query cache uit staan op een beetje server? Ik weet dat wij er bij een aantal applicaties nogal baat bij hebben dat 'ie aan staat.

[Xantios]

Ik zou het inderdaad in de database bewaren,
als je een beetje een efficiënte query gebruikt moet dat prima gaan.

sterker nog, je krijgt de Query gewoon cadeau!
al met al, als de database dat niet kan hebben, dan mag je meteen in de pen klimmen om een offerte te gaan schrijven voor meer database servers :-P

[djluc]

Je hebt al caching zeg je, dan is het toch gewoon implementeren in de database, want dat is handig te beheren. Vervolgens de juiste cache instellingen maken zodat dit deel van de cache vernieuwd wordt bij een wijziging. klaar. Best of both worlds op basis van de standaard aanpak die je toch al gebruikt.

[Verwijderd]

Pogostokje schreef op vrijdag 03 februari 2012 @ 21:16:
De overhead moet dus minimaal zijn want het wordt maar zelden gebruikt.

Dan is het juist toch geen enkel probleem? Als de query maar zelden aangeroepen wordt, dan is de performance impact toch ook niet groot? Of bedoel je de overhead van de extra if-statment?

[pedorus]

De query wordt altijd aangeroepen, maar levert zelden wat op. De grap is natuurlijk dat als je een storingsmededeling neerzet omdat zeg de database-server slecht bereikbaar is, dat vervolgens het probleem nog groter wordt. Het lijkt me daarom makkelijker om gewoon een php-include te doen naar een aanpasbaar bestandje. Kun je gelijk alle pagina's eventueel tijdelijk afkappen na de mededeling bijvoorbeeld ("Het is nu erg druk en we zijn bijna over de bandbreedte heen. Klik hier om deze pagina te bookmarken om het over enkele dagen nogmaals te proberen").

[Pogostokje]

pedorus schreef op zondag 05 februari 2012 @ 21:12:
De query wordt altijd aangeroepen, maar levert zelden wat op.

Precies.
Ik heb een draft voor dit nu klaar liggen, eens kijken wat de impact is op een rustig avondje deze week.

[borft]

en daarbij, als je een include gebruikt, dan zorgt je kernel dat die file in je diskcache staat, dus dat gaat ook supersnel. (Waar dacht je trouwens dat je sessie data vandaan komt?)

als dat nog te traag is, dan kan je een memcache server gebruiken; maar dat lijkt me hier redelijk overkill

[SoulWar1]

Een memcache server verschilt qua snelheid niet zoveel met een bestand van disk lezen, je zit immers met de netwerk overhead. Het snelste na lokaal geheugen is shared memory, zoals APC en Zend Data Cache. Het voordeel van memcache tov disk en shared memory zit hem in de schaalbaarheid, de cache is niet meer gebonden aan één machine maar kan door meerdere webservers worden gebruikt.

Maar voor zoiets simpels als de TS wilt lijkt me elke optie in orde.

[GlowMouse]

NMe schreef op zaterdag 04 februari 2012 @ 11:52:
[...]

En waarom zou de query cache uit staan op een beetje server? Ik weet dat wij er bij een aantal applicaties nogal baat bij hebben dat 'ie aan staat.

Omdat er bij een update of delete-query elementen uit gewist moeten worden en hij dmv een mutex alle queries ophoudt. Als applicatiebouwer kun je, als je een query echt niet snel kunt krijgen, het resultaat beter in een cache-tabel opslaan (of op externe software als memcached vertrouwen, hoewel dat nauwelijks extra voordeel oplevert).

In het geval van TS is de query niet zwaar maar kost het wel een roundtrip. Misschien haalt hij al ergens settings op en kan hij die roundtrip uitsparen door queries te combineren. Afhankelijk van de drukte van de site, zou ik gewoon die query draaien of anders kiezen voor zoiets in .htaccess:
RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1 (ip-adres van TS)
RewriteRule ^(.*)$ down.php [L]
Daarnaast zou ik eens kijken waarom de database zo zwaar belast wordt. Vaak kun je met een paar kleine ingrepen heel veel verbeteren.

[ Voor 28% gewijzigd door GlowMouse op 06-02-2012 01:47 ]

[Patriot]

Beetje vreemde cachewerking dan. Dat is toch vragen om problemen? Lijkt me logischer dat een query-cache gewoon geleegd wordt als de brongegevens veranderen.