Apache + php en caching

[chielsen]

Ik gebruik xcache om php te cachen. Dit werkt opzich prima. Het is alleen zo dat als ik de pagina voor de eerste keer opvraag dat het toch vrij lang duurt.
Nou ok dan kan ik begrijpen. Maar als ik bijv (op een dev site, waar ik alleen kom) 12 uur later weer komt, duurt het eerst weer lang (en is ie daarna weer snel).

Ik dacht dus dat de bestand weer uit de cache waren, maar als ik in de xcache admin kijk stonden ze er gewoon nog in. Is het soms iets anders. Kan apache niet meteen bij dat geheugen oid?

[Mikey]

virtuele server ?

[chielsen]

Ja...

[Mikey]

lijkt erop of de scheduler jouw vm naar achteren plaatst omdat die niets te doen heeft, en voorrang geeft aan drukkere vm's

[maxnet]

Kan apache niet meteen bij dat geheugen oid?

Wellicht weggeswapt?
Swap bestand in gebruik? (check daarbij zowel guest als host).

[chielsen]

Oh excuus voor de typo's in mijn OP.

Swap wordt niet gebruikt. Het zou idd iets kunnen zijn dat het te rustig is, maar ik heb wel het idee dat het alleen de bestanden zijn die een tijd niet geopend zijn, als ie het gehele geheugen "naar achteren schuift" dan zouden de andere pagina's ook traag moeten laden.
Het is trouwens gebaseerd op Xen, dus ik weet niet of die dat ook doet.

[PreServer]

het kan io problemen zijn op je vps
het kan zijn dat je page veel queries doet die gecached word (en als je na 12 uur weer terug komt uit de cache gegooit zijn)
het kan zijn dat het een grote page is met veel includes die xcache opnieuw moet compilen allemaal omdat de garbage collector is afgegaan

[chielsen]

het kan io problemen zijn op je vps
het kan zijn dat het een grote page is met veel includes die xcache opnieuw moet compilen allemaal omdat de garbage collector is afgegaan

Ja dat lijkt me de meest waarschijnlijke. GC staat op 4 uur. Het probleem is alleen dat in de admin van xcache de bestand nog gewoon stond alsof ze al 12 uur oud zijn.

[Wido]

Het gebeurd vaker dat er simpelweg met een cron met "wget" of "lynx" de cache warm wordt gehouden van een website.

Op een externe machine doe je eens in de X minuten een aanvraag naar de website, zo blijft de cache daar warm.

[wonko]

xcache is ook geen resultatencache, maar een opcode / variable cache. De pagina's zelf moeten nog altijd door PHP opgebouwd worden.

[chielsen]

Het gebeurd vaker dat er simpelweg met een cron met "wget" of "lynx" de cache warm wordt gehouden van een website.

Op een externe machine doe je eens in de X minuten een aanvraag naar de website, zo blijft de cache daar warm.

Ja daar zat ik dus al aan te denken.

@wonko ik weet niet wat je bedoelt met resultatencache? Het gebeurt ook op pagina's die niet eens van een database gebruikmaken. Ik wil idd de opcode cachen, maar het lijkt dat die cache verloopt na een paar uur, terwijl ze niet zouden mogen verlopen (en de admin aangeeft dat ze nog gecached zijn).

Ik zal mijn host eens vragen of er misschien geheugen "naar achter wordt geschoven".

[File1eu]

Ik weet niet of jou host dat weet en/of dat toe zal geven. Je kan eerst een cron-job maken om het probleem te lokaliseren. Als je dit elk uur of elk half uur draait:

wget http://jouwsite >/dev/null 2>&1

Je webstatistieken worden wel wat onnauwkeurig op deze manier

[The-BosS]

Ik weet niet of jou host dat weet en/of dat toe zal geven. Je kan eerst een cron-job maken om het probleem te lokaliseren. Als je dit elk uur of elk half uur draait:

wget http://jouwsite >/dev/null 2>&1

Je webstatistieken worden wel wat onnauwkeurig op deze manier

Ik zou eerst even het volledige topic lezen, TS runt op een VPS server en is dus zijn eigen host. Dit ter zijde, het cronjob verhaal is ook al paar keer aan bod gekomen.

[T. Verhaeg]

Heb je deze oplossing ondertussen al eens geprobeerd en biedt het een oplossing?

[brammetjeh]

Ik ben ook erg benieuwd loop hier soms ook tegenaan en zoek naar een oplossing voor mijn bestaande vps