[PHP] Parsetime verkleinen

[getty]

Ik heb voor mijn site een portal, deze portal is voor een groot deel al voor-gerenderd. Er worden nog 2 of 3 queries uitgevoerd tijdens het laden. Nu vraag ik me een paar dingen af. Waarom is de parsetime in IE zoveel malen groter dan in Mozilla. Is minimaal 0,9 sec. in IE tegenover maximaal 0,05 sec. in Mozilla. Is een behoorlijk groot verschil.

Verder vraag ik me af hoe het met de frontpage van Tweakers.net gaat, deze geeft namelijk aan meestal 0,01 sec. als parsetime aan. Is deze helemaal voor-gerenderd?

[Tux]

Een parsetime verschil tussen twee browsers is wel heel vreemd. De parsetime die gemeten wordt bestaat alleen uit het parsen van PHP code en niet uit de tijd dat het duurt om de pagina over het internet te versturen en de HTML te renderen ofzo.

[Harm]

getty schreef op 03 januari 2004 @ 23:13:
Verder vraag ik me af hoe het met de frontpage van Tweakers.net gaat, deze geeft namelijk aan meestal 0,01 sec. als parsetime aan. Is deze helemaal voor-gerenderd?

Het grootste deel van de Frontpage van T.net is inderdaad prerendered. Updatetrackers enzo zijn allemaal gecached en worden één keer in de vijf minuten bijgewerkt geloof ik; voor abonnees realtime.

[André]

Het (php) parsen heeft helemaal niets met de browsers te maken. Php maakt een pagina en stuurt die naar je browser, en of dat nu mozilla of IE is maakt niet uit. Dus een extra query maakt ook niets uit.

Het kan wel zijn dat sommige browsers er langer over doen om de uitgepoepte html te parsen, naar dat heeft nog steeds niets met de php te maken.

[getty]

Tux schreef op 03 januari 2004 @ 23:15:
Een parsetime verschil tussen twee browsers is wel heel vreemd. De parsetime die gemeten wordt bestaat alleen uit het parsen van PHP code en niet uit de tijd dat het duurt om de pagina over het internet te versturen en de HTML te renderen ofzo.

Dit leek mij ook, maar toch neem ik een groot verschil waar.

[Erkens]

getty schreef op 03 januari 2004 @ 23:22:
[...]

Dit leek mij ook, maar toch neem ik een groot verschil waar.

hoe meet je je parsetime dan?

[getty]

Erkens schreef op 03 januari 2004 @ 23:23:
[...]

hoe meet je je parsetime dan?

Door middel van een php functie die ik hier op het forum heb gevonden.
http://gathering.tweakers.net/forum/view_message/2123532

[Verwijderd]

er is een verschil tussen de parse en de rendertime, maar dat had je zelf ook al door.

Parsen gebeurd op de server, die maakt html codes

Renderen gebeurd op de client, de browser maakt van je html een output naar je videokaart (min of meer)

[Erkens]

getty schreef op 03 januari 2004 @ 23:24:
[...]

Door middel van een php functie die ik hier op het forum heb gevonden.
http://gathering.tweakers.net/forum/view_message/2123532

mja, maar mijn vraag was eigenlijk "waar" meet je (sorry had ik beter moeten formuleren)

edit:
ff iets duidelijk dan
waar stop je met het meten van de parsetime, voor of na je output?

[ Voor 16% gewijzigd door Erkens op 03-01-2004 23:27 ]

[getty]

Erkens schreef op 03 januari 2004 @ 23:26:
[...]

mja, maar mijn vraag was eigenlijk "waar" meet je (sorry had ik beter moeten formuleren)

Wat bedoel je met "waar"? Op welke site?

[getty]

Erkens schreef op 03 januari 2004 @ 23:26:
[...]

mja, maar mijn vraag was eigenlijk "waar" meet je (sorry had ik beter moeten formuleren)

edit:
ff iets duidelijk dan
waar stop je met het meten van de parsetime, voor of na je output?

Ah, zo. Nee dat is na de output. Dus pagina eindigd zo:

PHP:

</html>
<!-- Parsetime: <?php echo timing('end'); ?> -->

Maar hij gaat het toch pas versturen als hij helemaal aan het eind van de pagina is, of gaat daar mijn hersenkronkel fout...

Edit:
Daar gaat het natuurlijk fout ja. Ik kan de parsetime niet meten aangezien ik niet alles mbv php uitspuug, maar ook veel rechtstreeks als html. En dan verstuurd hij het tussendoor al naar de client toe.

[ Voor 20% gewijzigd door getty op 03-01-2004 23:33 ]

[Erkens]

getty schreef op 03 januari 2004 @ 23:30:
[...]


Ah, zo. Nee dat is na de output. Dus pagina eindigd zo:

PHP:

</html>
<!-- Parsetime: <?php echo timing('end'); ?> -->

Maar hij gaat het toch pas versturen als hij helemaal aan het eind van de pagina is, of gaat daar mijn hersenkronkel fout...

kan uitmaken, maar test het eens, prop de parsetime eens in een var voor je je output begint, en echo die var dan

[getty]

kan uitmaken, maar test het eens, prop de parsetime eens in een var voor je je output begint, en echo die var dan

Dat is dus het probleem, ik heb php code tussen html staan, daardoor wordt er de hele tijd output naar de client gestuurd en kan ik de parsetime niet meten.

[creative8500]

getty schreef op 03 januari 2004 @ 23:35:
[...]


Dat is dus het probleem, ik heb php code tussen html staan, daardoor wordt er de hele tijd output naar de client gestuurd en kan ik de parsetime niet meten.

Waarom kun je niet hélemaal vooraan dat [html+php]-combi-bestand die timer laten beginnen?

[Erkens]

getty schreef op 03 januari 2004 @ 23:35:
[...]


Dat is dus het probleem, ik heb php code tussen html staan, daardoor wordt er de hele tijd output naar de client gestuurd en kan ik de parsetime niet meten.

gaat het overigens over de site die je hier als homepage hebt ingesteld?
zoja, ik heb hier met zowel IE als mozilla parsetijden van +/- 0.02 sec

[Tux]

getty schreef op 03 januari 2004 @ 23:35:
[...]


Dat is dus het probleem, ik heb php code tussen html staan, daardoor wordt er de hele tijd output naar de client gestuurd en kan ik de parsetime niet meten.

Dan kan je tijdelijk even ob_start(); aan het begin van de code en ob_end_flush(); aan het eind van je code zetten. Dan output hij pas aan het eind.

Maar het zou niet veel uit moeten maken.

[getty]

Ik vrees dat het tijd wordt dat ik naar bed ga. Het bleek dat ik in IE in was gelogd op de portal en in Mozilla niet. Hierdoor hoefde Mozilla niet te wachten op een zware query die in IE wel gedaan moest worden. Nu liggen beide browsers ongeveer op dezelfde parsetijd. Helaas wel op de tijd van IE, maar daar kan ik dan nu aan gaan werken. Dat is namelijk een van de laatste onderdelen die niet geprerendered is.

[getty]

Erkens schreef op 03 januari 2004 @ 23:38:
[...]

gaat het overigens over de site die je hier als homepage hebt ingesteld?
zoja, ik heb hier met zowel IE als mozilla parsetijden van +/- 0.02 sec

Yep, dat is hij. Maar ik ben dus al achter het probleem gekomen, staat in mijn vorige reactie. Stom stom stom.

[Tux]

Wat voor enorme resultsets haal je dan op? Want 0.9 sec is wel extreem hoog. Of heb je een for loop met queries ofzo?

[getty]

Tux schreef op 03 januari 2004 @ 23:44:
Wat voor enorme resultsets haal je dan op? Want 0.9 sec is wel extreem hoog. Of heb je een for loop met queries ofzo?

Nee, 1 query met 10 resultaten. Maar deze is blijkbaar niet helemaal goed ofzo. Het is een query over 3 tabellen met respectivelijk 300.000, 150.000 en 15.000 record erin. Maar op zich zou dat wel sneller moeten kunnen gaan. Toch maar eens naar mijn indexen kijken

[Skaah]

Meet je op de computer waar de server op draait? Zeg maar, met http://localhost? Een deel van de processortijd voor PHP wordt dan door de browser gebruikt.
Als je het proces van je browser op een lagere prioriteit (bijv. Laag) zet dan heb je een eerlijkere vergelijking.

[getty]

Skaah schreef op 04 januari 2004 @ 12:09:
Meet je op de computer waar de server op draait? Zeg maar, met http://localhost? Een deel van de processortijd voor PHP wordt dan door de browser gebruikt.
Als je het proces van je browser op een lagere prioriteit (bijv. Laag) zet dan heb je een eerlijkere vergelijking.

Nee, gelukkig niet Mijn adsl lijntje trekt die site niet.