[PHP/MYSQL] Hoe veel zware pagina's snel serverside cachen?

[Gerwin]

De situatie is de volgende. Ik beheer een grote Nederlandstalige website met allemaal dynamische pagina's die eigenlijk elk uur (niet minder dan 60 minuten in iedergeval) bijgewerkt wordt met informatie. Elke pagina heeft een heel zwaar php script dat een hele boel selectie's doet op de database en hieruit tabellen, teksten etc. opmaakt.

De pagina's worden nu gecached door elke eerste bezoeker die de pagina opvraagt. Bij elke hit wordt er gekeken met PHP of er een cache is en of de tijd van het bestandje nog niet te oud is. Dit gaat allemaal prima, als het bestandje nog niet oud is (3600 seconden) dan presenteerd hij deze supersnel aan de bezoeker.

Echter nu komt het. Elke eerste bezoeker die zit met een gigantisch lange laadtijd. Ik heb er eens een PHP scriptje opgezet om te kijken hoelang het allemaal duurt voordat zo'n zware pagina gemaakt is en in cache gezet is. Totaal komt dit ongeveer op (schrik niet) 13 seconden. Elke eerste bezoeker van elke pagina van de website elk uur moet dus 13 seconden wachten voordat er iets verschijnd. Dit is veel te lang.

Eigenlijk wil ik dat die ladtijd veel korter word. Maar aan de andere kant een Cron te gaan runnen op elke pagina op de site (als ik zo kan achterhalen hoeveel het er precies zijn is onbegonnen werk, daarbij slurpt dit bandbreedte. Mijn vraag is nu: Hoe kan ik dit het beste aanpakken? Zijn er snellere methode's op pagina's te cachen zonder dat de laadtijd in gedrang komt?

Ik heb aan het optimaliseren van de Mysql query's weinig gehad tot nu. In totaal zijn er nu maar 6 per pagina (dit worden er meer) maar met veel overlappingen en dit doort zaakjes "text.linx = linx.id AND...." bovendien een "LIMIT 0,200 op elke query" omdat ik op voorhand niet altijd weet hoeveel ik er exact nodig heb. Reden dat ik die grote selectie's doe en niet gewoon op de pagina zelf is dat ik een doorlopende lijst wil hebben verdeeld over de pagina en "RAND()". Als ik kleine selectie's doe dan heb ik kans op dubbele.

[NMe]

Waarom maak je de cache niet gewoon aan op het moment dat je de pagina toevoegt/aanmaakt?

[Verwijderd]

Misschien omdat hij dan met die 13s laadtijd zit, en die laadtijd wilt hij helemaal weg hebben.

[NMe]

Die laadtijd kun je beter bij de beheerder, die de pagina aanpast, hebben, dan bij een willekeurige gebruiker die net de pech heeft om als eerste die pagina op te vragen.

Verder: 13 seconden is behoorlijk lang. Staan je indexen goed?

[ Voor 17% gewijzigd door NMe op 07-07-2005 00:52 ]

[Bosmonster]

Ik heb aan het optimaliseren van de Mysql query's weinig gehad tot nu. In totaal zijn er nu maar 6 per pagina (dit worden er meer) maar met veel overlappingen en dit doort zaakjes "text.linx = linx.id AND...." bovendien een "LIMIT 0,200 op elke query" omdat ik op voorhand niet altijd weet hoeveel ik er exact nodig heb. Reden dat ik die grote selectie's doe en niet gewoon op de pagina zelf is dat ik een doorlopende lijst wil hebben verdeeld over de pagina en "RAND()". Als ik kleine selectie's doe dan heb ik kans op dubbele.

Hier snap ik niks van? Weet je zeker dat daar niet gewoon iets te optimaliseren valt?

Kan me bijna niet voorstellen dat dat niet een heel stuk efficienter kan.

[Sybr_E-N]

Gerwin schreef op donderdag 07 juli 2005 @ 00:45:
Ik heb aan het optimaliseren van de Mysql query's weinig gehad tot nu. In totaal zijn er nu maar 6 per pagina (dit worden er meer) maar met veel overlappingen en dit doort zaakjes "text.linx = linx.id AND...." bovendien een "LIMIT 0,200 op elke query" omdat ik op voorhand niet altijd weet hoeveel ik er exact nodig heb. Reden dat ik die grote selectie's doe en niet gewoon op de pagina zelf is dat ik een doorlopende lijst wil hebben verdeeld over de pagina en "RAND()". Als ik kleine selectie's doe dan heb ik kans op dubbele.

Lijkt me heel stug dat je niet wat seconden kan winnen. Ik zou bijna denken dat je structuur van je applicatie niet helemaal op orde hebt. En zijn het echt alleen de SQL queries die zo lang duren?

[Icey]

Zomaar een idee, maar is het niet handig om 1x per uur de server zelf een cronjob laten uitvoeren die de cache ververst? Dus 1 cron die alles ververst? Of is dat niet mogelijk?

[thomaske]

Of misschien de persoon die na 1 uur de pagina bezoekt, stiekem toch de oude laten zien, en dan ondertussen (met een extern script, oid) de cache vernieuwen..

[ripexx]

Zoals -Nme- al aangeeft is het waarschijnlijk handiger bij een aanpassing in de DB (update of insert) een nieuwe cached pagina te genereren. Verder snap ik niet waarom een paar 100 results zoveel tijd in beslag nemen. Ga eerst een in een test omgeving kijken hoelang je query er daadwerkelijk over doet. Ga dan je SQL staements optimaliseren. Kan dit niet zit je waarschijnlijk met het probleem dat je DB modelbrak is.

De kunst is in ieder geval om te achterhalen waar de extreme duur in zit. Dit kan je zelf gewoon testen. Daarnaast zou je een tussen oplossing kunnen bedenken. Door bijvoorbeeld bij te houden welke pagina's ge-cached moeten worden.Dit kan gewoon in een simpel text bestand waarna je dit bijvoorbeeld elk uur langs loopt.

[Bosmonster]

thomaske schreef op donderdag 07 juli 2005 @ 12:24:
Of misschien de persoon die na 1 uur de pagina bezoekt, stiekem toch de oude laten zien, en dan ondertussen (met een extern script, oid) de cache vernieuwen..

Slim Het zijn de kleine dingen die het hem doen

(mocht optimaliseren niet werken)

[ Voor 6% gewijzigd door Bosmonster op 07-07-2005 14:34 ]

[chris]

thomaske schreef op donderdag 07 juli 2005 @ 12:24:
Of misschien de persoon die na 1 uur de pagina bezoekt, stiekem toch de oude laten zien, en dan ondertussen (met een extern script, oid) de cache vernieuwen..

Met system kan je heel mooi een extern script die cache laten maken. Bijvoorbeeld:

PHP:

system("/usr/bin/php myscript.php > /dev/null 2> /dev/null &");

Ten eerste heb je (vaak, volgens mij altijd) geen beschikking over je environment variabelen in system, ten tweede is die & heel handig: deze zorgt er voor dat het script op de achtergrond wordt uitgevoerd zodat het script niet hangt. Ook die > en 2> zorgen er voor dat de output geredirect worden, zodat het aanroepende script niet op output wacht .

[Verwijderd]

Ik zou toch naar je queries kijken. Een pagina mag eigenlijk niet meer dan 10 queries hebben (en dat is al aan de hoge kant).

zet EXPLAIN voor elke SELECT query om te kijken hoe en of je indexen gebruikt worden. Join zoveel mogelijk tables via foreign keys.

[ Voor 7% gewijzigd door Verwijderd op 07-07-2005 19:55 ]

[Verwijderd]

Ik denk niet dat je zomaar lukraak kunt roepen dat je max 10 queries mag hebben, ligt natuurlijk ook aan je systeem. M'n CMS voert soms meer dan 30 queries uit voor authenticatie, authorisatie, statistics, user tracking, preferences, de content en afhankelijk van de pagina nog een aantal.

Maar de max page load time die ik heb gezien is tot nu toe een paar seconde geweest, waarvan het grootste deel bestond uit het doorsturen van de HTML naar de client (ik neem the laatste tijdmeting na de laatste flush). De echt page generation time is altijd onder de halve seconde bij mij, zelfs bij'zware database pagina's met 50+ queries... en dat allemaal met de nodige tientallen hits/seconde op een weinig florisante server...

Zoals -NME- al aangeeft zou ik eens naar de DB structuur en de indices daarop gaan kijken. Daarnaast kunnen meerdere factoren meespelen. Staat de DB op dezelfde machine als de webapp, is het een dedicated server of een overwerkte gedeelde server, dat soort dingen zouden je 13 seconde page load time ook kunnen verklaren.

Cachen is misschien wel een goed idee als de page load time echt niet lager kan, maar ik begrijp uit het verhaal van de TS dat de 13 seconden juist nodig zijn voor het cachen van de pagina. Misschien heb je er wat aan uit te zoeken hoeveel van deze 13 seconden gaat zitten in het genereren van de pagina en hoeveel in het opslaan in de cache. Ik kan me niet voorstellen dat het generen van de pagina boven de 5 seconden uit komt, dus misschien kun je wat verbeteringen aanbrengen in het cachen zelf?

En als het allemaal echt niet lukt, dan kun je er nog altijd vanaf maken met een melding naar de user die de caching gaat verzorgen met een animated GIF van een random progress bar en een ignore_user_abort (of equivalent) in je webapp

[Verwijderd]

En vermijd de SELECT *, en zorg dat er alleen de velden worden opgehaald die noodzakelijk zijn.
Probeer aan je hoster te vragen of hij het mysql_slow_query-log aan zet.
Dan kan je precies zien waarom hij zo traag wordt...

[Verwijderd]

Tsja je gaat ook niet op de motor met zijn vieren op vakantie. Dan neem je een auto. Oftewel gebruik de juiste taal voor de juiste job. Zo'n beetje elk project wat antwoord moest geven op dit vraagstuk draait op Java...

[Eskimootje]

Verwijderd schreef op donderdag 07 juli 2005 @ 19:54:
Ik zou toch naar je queries kijken. Een pagina mag eigenlijk niet meer dan 10 queries hebben (en dat is al aan de hoge kant).

zet EXPLAIN voor elke SELECT query om te kijken hoe en of je indexen gebruikt worden. Join zoveel mogelijk tables via foreign keys.

Hoe heb je dat nou weer verzonnen? Een goed opgezette database kan veel meer dan 10 queries per pagina aan, ik heb zelfs gezien met 100en die gewoon goed doorliepen (wel simpelere queries voor een gedeelte)

[crisp]

Verwijderd schreef op vrijdag 08 juli 2005 @ 10:12:
Tsja je gaat ook niet op de motor met zijn vieren op vakantie. Dan neem je een auto. Oftewel gebruik de juiste taal voor de juiste job. Zo'n beetje elk project wat antwoord moest geven op dit vraagstuk draait op Java...

En waarom zou PHP niet geschikt zijn dan? Is onze frontpage ook zo traag? of dit forum?
Je opmerking slaat kant noch wal en is in deze discussie totaal niet relevant...

[Verwijderd]

want? er wordt gevraagd naar caching, laat dat nou allemaal door frameworks ondervangen zijn. Ik ben gewoon voor de "right tool for the right job". Daar kun je het toch gewoon over hebben

[crisp]

Verwijderd schreef op vrijdag 08 juli 2005 @ 10:33:
want? er wordt gevraagd naar caching, laat dat nou allemaal door frameworks ondervangen zijn. Ik ben gewoon voor de "right tool for the right job". Daar kun je het toch gewoon over hebben

Dus omdat er dergelijke frameworks bestaan voor java is java een betere taal?
En fyi: wel eens gehoord van Zend, eAccelarator, Turk's mmCache?

[Verwijderd]

Nee, dat zeg ik toch helemaal niet, interpreteren is geloof ik ook een vak appart. Ik zeg de juiste tool voor de juiste job. Als jij je prettig voelt met php op je frontend moet je dat vooral doen. Als je caching wilt inbouwen lijkt mij php daar domweg gewoon niet geschikt voor (het wel of niet kunnen is iets anders dan geschikt zijn). Dus makkelijker lijkt mij gebruik maken van bestaande frameworks die dit vraagstuk tackelen.

[MBV]

Jij suggereert dat je een bestaande applicatie gaat vertalen naar Java omdat je een caching probleem hebt? Ik geloof dat jij nog niet voor een baas hebt geprogrammeerd ofzo. Dat is gewoon niet te doen, kost bergen met geld aan ontwikkelen en testen.
PHP kan prima met caching omgaan. En ik wil best wel een framework maken in PHP voor caching, volgens mij is dat echt minder dan 8 uur werk...

Los daarvan zou het waarschijnlijk caching overbodig maken, omdat ik vermoed dat de algoritmen van de TS niet optimaal zijn. Als je dingen opnieuw gaat maken zie je veel sneller waar het beter kan.

[Verwijderd]

Ik weet niet hoeveel rechten je hebt op je server en welk besturingssyteem je hebt, maar je zou misschien kunnen denken aan een cron job. Als je deze om de 3600 seconden een php script laat uitvoeren die anders bij een client word uitgevoerd, dan heeft geen enkele bezoeker last.

Bij het laden (en misschien bij het wijzigen) van een reeds bestaande( oude pagina), wordt deze pagina toegevoegd aan een update lijst. Zodra de de job begint worden alle pagina's die in de lijst staan geladen en gecached.

--- zojuist over het bericht van Icey heen gelezen. Cron job was al voorgesteld... ---

[ Voor 9% gewijzigd door Verwijderd op 08-07-2005 11:14 ]

[Verwijderd]

MBV schreef op vrijdag 08 juli 2005 @ 10:57:
Ik geloof dat jij nog niet voor een baas hebt geprogrammeerd ofzo.

Gut gut, dat lijkt wel een standaard GoT reactie te worden van mensen die geen argumenten kunnen leveren.

MBV schreef op vrijdag 08 juli 2005 @ 10:57:
Jij suggereert dat je een bestaande applicatie gaat vertalen naar Java omdat je een caching probleem hebt?
[..]
Als je dingen opnieuw gaat maken zie je veel sneller waar het beter kan.

Dus wel opnieuw doen maar een andere aanpak met een andere techniek is dan geen optie?

Als iedereen het hier al eens is dat er een hoop moet veranderen op de back-end waarom dan zo kortzichtig reageren als ik de gebruikte technieken ter discussie stel?

[chris]

Ik moet ook php gebruiken van m'n baas, omdat php-ontwikkelaars veel makkelijker te vinden zijn, en goedkoper zijn. En misschien is TS wel helemaal niet thuis in java. Ondanks dat ik php heel erg ranzig vindt, is het prima geschikt voor caching. T.net draait helemaal op php, en er zijn zat andere grote sites die op php draaien.

[Bosmonster]

Een andere techniek is meestal geen optie. Bovendien is dat ook niet waar de TS om vraagt.

Daarom is die discussie hier vrij zinloos.

"We doen al jaren alles in PHP, maar heb nu een caching probleempje en iemand op het forum zegt dat ik nu Java moet gaan gebruiken. Kun je mij een cursusje, een paar maanden en een nieuwe server kado doen baas?"

[Verwijderd]

Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

[RedRose]

Je moet eerst achterhalen waar zich precies de bottlenecks bevinden. Dus: weten dat een pagina een lange laadtijd heeft is leuk, maar als je bij _elke_ query op de pagina even een tijdsverschil meet en daarbij de query laat zien, zie je precies waar je moet optimaliseren. Doe dat ook voor stukken code, want het kan ook heel goed zijn dat je 4 in elkaar stekende loops hebt, die efficienter kunnen. Check ook je database-connectiviteit.

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:43:
Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

Sorry, maar je lult uit je nek. Een 'professional' zal eerst kijken, ongeacht de taal, waar zich bottlenecks bevinden en die proberen op te lossen. Hij weet dat er een lange tijd over gedaan is om de code te schrijven en dat dat dus veel geld gekost heeft. Je koopt niet een huis dat je helemaal opknapt over tig jaar, om vervolgens te zeggen: ok, dit huis zuigt, ik steek het in de fik.

[ Voor 43% gewijzigd door RedRose op 08-07-2005 11:46 ]

[Bosmonster]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:43:
Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

Wat een verwaandheid...

Java is hier gewoon geen optie.. is dat nu zo moeilijk te begrijpen als professional?

[Verwijderd]

Bosmonster schreef op vrijdag 08 juli 2005 @ 11:44:
Java is hier gewoon geen optie.. is dat nu zo moeilijk te begrijpen als professional?

Ik zeg ook helemaal niet dat je java MOET gebruiken, ik probeer alleen mensen eens te laten nadenken over de technieken die ze gebruiken, is dat nu zo moeilijk te begrijpen?

Er zijn 6000 wielen op de markt, er is er vast wel een die je aansluit bij je wensen...

RedRose schreef op vrijdag 08 juli 2005 @ 11:43:
Sorry, maar je lult uit je nek. Een 'professional' zal eerst kijken, ongeacht de taal, waar zich bottlenecks bevinden en die proberen op te lossen. Hij weet dat er een lange tijd over gedaan is om de code te schrijven en dat dat dus veel geld gekost heeft. Je koopt niet een huis dat je helemaal opknapt over tig jaar, om vervolgens te zeggen: ok, dit huis zuigt, ik steek het in de fik.

Tsja dan lul je ook uit je nek, want ik zeg met andere woorden precies hetzelfde

[ Voor 39% gewijzigd door Verwijderd op 08-07-2005 11:52 ]

[RedRose]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:49:
[...]
Ik zeg ook helemaal niet dat je java MOET gebruiken, ik probeer alleen mensen eens te laten nadenken over de technieken die ze gebruiken, is dat nu zo moeilijk te begrijpen?

Er zijn 6000 wielen op de markt, er is er vast wel een die je aansluit bij je wensen...


[...]

Tsja dan lul je ook uit je nek, want ik zeg met andere woorden precies hetzelfde

Nee, want ik bedoelde met platformonafhankelijkheid het volgende: stel je komt ergens binnen en er draait een zware php-app. Dan ga je niet zeggen: gebruik Java, want das beter. Je gaat (zoals ik in eerste instantie zei in mijn vorige post) proberen om in de bestaande code de bottlenecks weg te nemen. Ongeacht het gebruikte gebruikte platform, maar hier dus php.

[ripexx]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:43:
Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

Kom op zeg en reageer volwassen

Vaak is het gewoon weg niet mogelijk om zomaar even van platform te wisselen. Hiervoor heb je zowel de kennis als ervaring en middelen voor nodig. Verder kan ik dan net zo goed zeggen dat de TS .Net moet gaan gebruiken omdat daar nog een beter framework om heen zit en ik support direct bij MS kan inkopen.

Techniek is een issue bij het ontwerpen en niet als je later tegen problemen aan loopt. Verder lijkt het er eerder op dat de TS gewoon een aantal verkeerder keuzes heeft gemaakt ten aanzien van het database model en de gebruilte PHP constructies. Immers is het zelden noodzakelijk om zware caching te gaan gebruiken. Veelal is het interessanter om gewoon meer server power aan te schaffen. Als ik een goed werken chaching systeem moet laten bouwen kost mij dat al snel 1000 euro per dag en dan kan ik na een week twee dikke webservers voor kopen. Dus in de long run is het interessant maar dan kan je ook denken aan andere oplossingen.

Als ik kijk op mijn werk dan werken we op MS platforms only dus is .Net de toekomst. Alleen worden er nog steeds stukken VB en JScript gescheven omdat de rest ook daarin is geschreven. De technische jongens zouden graag switchen naar .Net maar het kosten plaatje is gewoon dus danig groot dat het niet gebeurt. Nieuwe add-ons worden dan wel in C#.Net geschreven. gewoon omdat je hier opnieuw begint met ontwerpen en je een nieuwe platform keuze kan maken. Maar dan nog is het noodzakelijk dat er scholing en opleiding plaats vindt want je wel immers wel dat er optimaal gebruik van wordt gemaakt.

[Bosmonster]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:49:
[...]
Ik zeg ook helemaal niet dat je java MOET gebruiken, ik probeer alleen mensen eens te laten nadenken over de technieken die ze gebruiken, is dat nu zo moeilijk te begrijpen?

Ja.. dat vind ik heel lastig te begrijpen. Want waarom zou je dat willen in een topic waarin iemand vraagt om een PHP oplossing?

Zit je ook in het grote BMW topic te spammen dat Mercedes ook een prima merk is? En dat de BMW rijders eens verder moeten kijken en dat ze anders dom zijn?

En als ze dat niet snappen, zeg je toch gewoon dat dat waarschijnlijk 'te hoog' gegrepen is voor de BMW rijders...

Mooie manier om te discussieren hoor...

[RedRose]

Ok, dus samengevat voor de TS:

• Bespreek je datamodel
• Time je queries
• Profile je code
• Draai in de tussentijd een cronjobje, maar hou daar mee op als de bottlenecks weg zijn
• Zoek eventueel naar een zwaardere server
• Ga voorzichtig kijken naar een ander platform en ben vervolgens daar 5 jaar mee bezig om het allemaal goed te krijgen.

[PowerFlower]

Back on topic vind ik leuk om even samen te vatten: er zijn dus drie realistische opties:

• Optimaliseer je PHP code en queries (sowieso altijd nuttig werk);
• -NME-'s oplossing "maak de cache aan op het moment dat je een wijziging doet" vind ik een slimme; en
• Don't underestimate the power of scheduled wgets

Die laatste - een cron van een wget - lijkt te brak voor woorden, maar is makkelijk te implementeren (dus goedkoop) en neemt veel van de pijn bij de bezoekers weg. En ik weet uit betrouwbare bron dat een aantal grote Nederlandse sites die op Tomcat draaien vrolijk alles met een wget cachen als de site veranderd is

De eerste oplossing is natuurlijk het netste en meest ideaal, maar waarschijnlijk ook het lastigste en meest tijdrovende (dus dat kun je rustigjes aan de komende maanden gaan doen, want nuttig is het sowieso). Blijft -NME-'s oplossing en die vind ik het mooist, simpel en effectief. Maar niets weerhoudt je er van alle drie te doen

_{RedRose, als jij nou ff mijn FO gaat analyseren ipv hier net iets eerder te posten wat ik post, damn you}

[ Voor 8% gewijzigd door PowerFlower op 08-07-2005 12:05 ]

[Verwijderd]

Bosmonster schreef op vrijdag 08 juli 2005 @ 11:57:
Ja.. dat vind ik heel lastig te begrijpen. Want waarom zou je dat willen in een topic waarin iemand vraagt om een PHP oplossing?

Zit je ook in het grote BMW topic te spammen dat Mercedes ook een prima merk is? En dat de BMW rijders eens verder moeten kijken en dat ze anders dom zijn?

En als ze dat niet snappen, zeg je toch gewoon dat dat waarschijnlijk 'te hoog' gegrepen is voor de BMW rijders...

Mooie manier om te discussieren hoor...

Nee, sorry no offence, maar dan snap je het echt gewoon niet. Zoals ik van het begin al zeg, right tool for the right job. De keuze bmw mercedes zou enkel zeggen dat je eclipse intelliJ wilt vergelijken

[Bosmonster]

Om maar weer even ontopic te komen. Ik ben wel heel benieuwd naar TS z'n PHP code. Daar moet toch wat mee te doen zijn.

Jammer dat hij zelf niet meer gereageerd heeft

[RedRose]

Verwijderd schreef op vrijdag 08 juli 2005 @ 12:05:
[...]

Nee, sorry no offence, maar dan snap je het echt gewoon niet. Zoals ik van het begin al zeg, right tool for the right job. De keuze bmw mercedes zou enkel zeggen dat je eclipse intelliJ wilt vergelijken

Dat zeg je inderdaad, maar je hebt nog geen enkel argument gegeven waarom de TS a) niet de right tool gebruikt b) hij zou moeten switchen. Verder ga je ook niet echt in op wat Bosmonster c.s. je proberen duidelijk te maken.

Bosmonster schreef op vrijdag 08 juli 2005 @ 12:09:
Om maar weer even ontopic te komen. Ik ben wel heel benieuwd naar TS z'n PHP code. Daar moet toch wat mee te doen zijn.

Jammer dat hij zelf niet meer gereageerd heeft

Ik hoop dat Gerwin het puntenlijstje nog even leest.

edit:
lol hieronder

[ Voor 39% gewijzigd door RedRose op 08-07-2005 12:13 . Reden: tssssk ]

[PowerFlower]

markvleth met Robinson Crusoe op een eiland:
Robinson: "damn we hebben alleen een hamer en die boom moet om"
markvleth: "met een zaag is dat onwijs makkelijk!"
Robinson: "thx dude "

_nofi

[Apache]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:43:
Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

Right tool for the job bepaald je tijdens de analyse, niet tijdens het optimizen, blijkbaar is er ingeschat geweest dat het wel snel genoeg ging zijn of dat die zaken wel te cachen zouden zijn met php.
Misschien had java beter geweest, misschien had het wel andere onoverkomelijke problemen met zich meegebracht of waren er andere praktische redenen waarom er niet voor java gekozen werd, hosting, geen in-house knowledge. Jou uitspraak slaat op het feit dat enkel java geschikt zou zijn voor grotere projecten terwijl dat meerdere mensen in dit topic daar met voorbeelden tegen in gaan. Dat jij als professional daar blijkbaar zo'n emotionele op niets slaande reactie geeft is natuurlijk belachelijk en zegt meer over jezelf dan de anderen.

Om even een nuttige bijdrage te leveren: http://www.danga.com/memcached/
Word gebruikt door MediaWiki dat gebruikt word door wikipedia, misschien vinden bepaalde mensen dat deze app ook in java geschreven zou moeten zijn maar ik denk toch dat die site een behoorlijke load te verwerken krijgt. Memcached word ook door bvb slashdot gebruikt.

Dan zoals crisp al zei kijk eens naar: eAccelarator of Turk's mmCache (zend Accellerator als je een budget hebt)

Als ik jou was zou ik het optimaliseren in dit geval aanpakken als volgt:

• Database model herbekekijken (inclusief indexes), je kan geen snelle app bouwen op een slecht & traag database model, caching is dan slechts een pleister
• Je queries herbekijken, zien ofdat je niet teveel data ophaalt en of je niet bepaalde verwerking van gegevens in je query kan doen, is vaak sneller dan meerdere malen in je php code over je query heen lopen
• http://xdebug.org/ gebruiken om je php code te profilen, zien waar er veel tijd/memory in kruipt
• Op je gestroomlijnde code caching toepassen, zien of je bepaalde caches pas moet regeneraten on update/delete en welke timebased bvb elk uur geupdate moeten worden, misschien cachen naar memcached of een eigen oplossing en dat in combinatie met iets wat je snelle php code ook nog eens in een gecompileerde toestand bijhoud

Ik ben de mythe van trage php apps of het feit dat php helemaal niet geschikt zou zijn voor grotere applicaties na al die jaren wel beu aan het worden. Php heeft zo langerzamerhand wel bewezen dat met de juiste developers er wel mooie dingen mee gedaan kunnen worden. Wat php zo'n slechte naam heeft gegeven zijn de beginnende developers die vaak code copy pasten tussen hun verschillende pages. Maar stel je voor dat 30% (getal volledig uit de lucht gegrepen) van de java developers in één classe zou ontwikkelen en het grootste deel van hun code in de main() zou plaatsen ...

[Verwijderd]

@apache
Klinkt allemaal mooi dat php het kan, maar zoals ik al eerder aangaf doet dat er niet toe. Je kunt het ook in brainfuck maken als dat je ding is. php een knullige taal? absoluut, inconsistente lib en andere issues, maar dat geld voor elke taal.

Feit blijft dat TS zijn back-end moet/wil gaan aanpassen, en daarin is altijd ruimte voor technieken. Tsja en bij java lopen ze nou eenmaal voor. Past het niet in de omgeving, prima, dan doe je er toch gewoon niets mee.

[ripexx]

Verwijderd schreef op vrijdag 08 juli 2005 @ 13:11:
@apache
Klinkt allemaal mooi dat php het kan, maar zoals ik al eerder aangaf doet dat er niet toe. Je kunt het ook in brainfuck maken als dat je ding is. php een knullige taal? absoluut, inconsistente lib en andere issues, maar dat geld voor elke taal.

Lekker geblaat in de ruimte, onderbouw eens in plaats van met een olifant oop een mug te schieten

Feit blijft dat TS zijn back-end moet/wil gaan aanpassen, en daarin is altijd ruimte voor technieken. Tsja en bij java lopen ze nou eenmaal voor. Past het niet in de omgeving, prima, dan doe je er toch gewoon niets mee.

Tuurlijk, je heb wat preformance problemen met enkele queries en we gaan zomaar even switchen van PHP naar Java. Tuurlijk ondersteunt je hoster het ook direct en ben je volledig bekend met de techniek, valkuilen en mogelijkheden. Verder vindt ik het maar kort door de bocht door te beweren dat Java voorloopt. Natuurlijk is Java aardig bezig maar de 'veel' Java programmeurs staan bekend dat ze veel liever ontwerpen en over designen.
[/sarcasme ]

Maar onderbouw je menig eens met voorbeelden en veroordeel eens niet zo. Een forum is om te discussieren maar dan wel met argumenten.

[Verwijderd]

ripexx schreef op vrijdag 08 juli 2005 @ 14:08:
Lekker geblaat in de ruimte, onderbouw eens in plaats van met een olifant oop een mug te schieten

Waar is me request scope?
Wat is de gehanteerde notatie voor functie namen?

ripexx schreef op vrijdag 08 juli 2005 @ 14:08:
Maar onderbouw je menig eens met voorbeelden en veroordeel eens niet zo. Een forum is om te discussieren maar dan wel met argumenten.

Java kent gewoon veel frameworks die zichzelf bewezen hebben. Denk daarbij aan iBates/Hibernate, Hivemind/Spring, Struts/Spring web, EhCache en zo kan ik nog wel doorgaan.

Doch houd ik een discussie liever abstract want anders verzand je enkel in een discussie waar je met techniekjes gaat smijten. En dat gebeurd op GoT al veel te vaak en heeft eigelijk weinig met discussieren van doen.

[NMe]

Verwijderd schreef op vrijdag 08 juli 2005 @ 13:11:
Feit blijft dat TS zijn back-end moet/wil gaan aanpassen, en daarin is altijd ruimte voor technieken. Tsja en bij java lopen ze nou eenmaal voor. Past het niet in de omgeving, prima, dan doe je er toch gewoon niets mee.

TS moet zijn back-end aan gaan passen, niet compleet vervangen. Het al dan niet overstappen op andere talen is niet relevant, zeker niet binnen de doelstelling van dit topic. In dit topic wordt gevraagd waar de bottleneck ergens kan zitten in een zware pagina en hoe de snelheid opgekrikt kan worden. Dit kun je prima in algemene termen uitleggen, zonder er andere talen bij te gaan halen. En als er dan al taalspecifieke dingen voorbij komen, dan graag in de taal die in de topictitel genoemd wordt.

Zodra een topicstarter aangeeft de mogelijkheid te hebben om een andere taal te gebruiken, dan kun je een suggestie doen, maar van de manier waarop in dit topic over en weer gediscussiëerd wordt over wel of niet Java gebruiken zonder dat de TS daar ook maar een reactie op heeft kunnen geven is eigenlijk gewoon triest. Ik stel voor dat deze aftakking van de discussie hier beëindigd wordt voor zover dat nog niet gebeurd was, op zijn minst totdat de topicstarter zelf de kans heeft gehad om er een reactie op te geven.

[Verwijderd]

Verwijderd schreef op vrijdag 08 juli 2005 @ 11:43:
Goed, okee, laat ook maar weer. Ik verwacht gewoon een forum met professionals en zo reageer ik dus ook. Misschien is mijn insteek dus te hoog...

Ik wilde hier nog wel even op reageren. Jij staat verbaast je over de antwoorden van anderen, ik zie dit hier, en ik zag het ook al in de thread over Ajax waar men (en ik ook) het niet met je eens kon worden.

Als je zoveel problemen hebt met het overbrengen van je standpunten naar professionals met expertise op hun eigen gebied, zou het dan niet aan jezelf liggen dan aan de mensen die het niet met je eens zijn? Je zult vast van een aantal zaken goed op de hoogte zijn, maar probeer nu niet ervaren mensen die zich dagelijks bezighouden totaal voor gek te verklaren met de tekst in de quote. Zeg dan gewoon "jongens misschien hebben jullie wel gelijk, hoe lossen jullie dat dan op", dan kom je denk ik een stuk verder en leer je er misschien ook nog wat van en kun je dat gebruiken in een andere discussie om wel je gelijk te halen.

[ Voor 19% gewijzigd door Verwijderd op 09-07-2005 00:51 ]

[Madcat]

wat misschien ook een idee is, is het genereren van deze pagina's door de server zelf.
dus elke 60 minuten zal het script met behulp van een cron job de pagina's uitekenen en hier html van maken.
zodat je alleen maar de html hoeft de includen, dan ben je iig van een hoop gezeur af.

[alienfruit]

Waarom zou je een pagina elke 60minuten opnieuw laten generen? Als de pagina toch al zo vaak wordt gewijzigd kan je het net als al eerder is geoppert, de "cache"-pagina laten generen op het moment dat de wijziging wordt gemaakt in de backend. Zolang de bezoeker zelf niks kan wijzigen bijv. door comments is dit een prima oplossing.

Maar goed eerst maar afwachten wat de reactie van de TS is... lijkt mij.

[ Voor 5% gewijzigd door alienfruit op 09-07-2005 01:21 ]

[NMe]

een_madcat schreef op zaterdag 09 juli 2005 @ 00:59:
wat misschien ook een idee is, is het genereren van deze pagina's door de server zelf.
dus elke 60 minuten zal het script met behulp van een cron job de pagina's uitekenen en hier html van maken.
zodat je alleen maar de html hoeft de includen, dan ben je iig van een hoop gezeur af.

Gerwin schreef op donderdag 07 juli 2005 @ 00:45:
Eigenlijk wil ik dat die ladtijd veel korter word. Maar aan de andere kant een Cron te gaan runnen op elke pagina op de site (als ik zo kan achterhalen hoeveel het er precies zijn is onbegonnen werk, daarbij slurpt dit bandbreedte.

[Grijze Vos]

Ik zie btw niet in hoe een cronjob bandbreedte slurpt. Doet nou werkelijk iedereen met wgets pages ophalen? Mja, ik heb wellicht het voorrecht dat ik mijn webservertje zelf beheer, en dus ook gewoon commandline php kan gebruiken. Wellicht heeft niet iedereen die mogelijkheid..

Overigens, over dat cachen. Ik snap het idee achter dat elk uur veranderen niet, re-cache gewoon wanneer het veranderd wordt. Verder lijkt 13s mij ook erg lang, zoals hierboven ook al gezegd is. Loop je queries eens langs, zou ik zeggen.

(Oh, en over die java<->php discussie, daar ga ik gewoon nog niet eens meer op in. Los van de bovenstaande argumenten is php een prima taaltje om een hoop mooie dingen in te maken, en java promoten "omdat het java is" is zo stokoud op dit forum. Frameworks zijn ook niet overal het antwoord op. Overigens, als ikzelf efficiente caching zou inbouwen zou het via een C++ programma zijn, wat via apache prima te koppelen is aan je php-programma. Last time I checked was C++ toch een stukkie sneller dan java. Anyways, zinloze discussie.)

[ Voor 35% gewijzigd door Grijze Vos op 09-07-2005 05:55 ]

[Xenon]

tips voor optimalisatie:

a) check je indexen ! --> zeer belangrijk
b) 'optimize' geregeld je tabellen (mysql statement)
c) smarty templates gebruiken en daar eventueel met caching werken?
d) Turck MMCache for PHP gebruiken?

[Madcat]

-NMe- schreef op zaterdag 09 juli 2005 @ 01:58:
[...]


[...]

waarschijnlijk is de oplossing zo standaard dat iedereen het kan bedenken

[Verwijderd]

een_madcat schreef op zaterdag 09 juli 2005 @ 12:56:

waarschijnlijk is de oplossing zo standaard dat iedereen het kan bedenken

Wat eigenlijk bedoeld wordt is dat je voortaan eerst de moeite moet nemen om even alle reacties te lezen. Niemand zit op zulke opmerkingen te wachten als het al minstens twee keer is genoemd.

Verder is dit topic zonder verdere input waardeloos, we vervallen in te algemene situaties. Iedere webdevver kan wel bedenken dat de topicstarter zijn indexen en queries moet nalopen, de PHP code moet analyseren, etc. Het is niet moeilijk om te achterhalen welk gedeelte van de code zo tijdrovend is. En als je dat hebt geisoleerd, kun je betrekkelijk eenvoudig zien of er nog iets aan te optimaliseren is.

Kortom, leuk, maar wij kunnen er verder weinig over zeggen natuurlijk. Maar volgens mij hoeven we niet veel van de TS te verwachten.

[alienfruit]

Ach, cheatah dan lost de TS het probleem toch niet op, wat maakt ons dat nou uit