[PHP] Wat zijn acceptable executiontimes?

[Dryw.Filtiarn]

Ik ben op dit moment druk bezig met wat php scripting en heb daarbij ook enige stats op de pagina staan. Hierbij valt me op dat de executiontime van begin tot het einde van het script tussen de 0.08 en 0.2 seconden ligt.
Mijn vraag is nu eigenlijk een beetje wat is nu een acceptabele execution time? Moet ik dan denken aan een honderdste seconde of is een seconde ook nog acceptabel?

[Config]

Hangt er echt vanaf wat voor omgeving je draait etc, en ook wat voor script. Voor admin scripts investeer ik nooit extra moeite om het te optimaliseren, voor scripts die productie-sites aansturen juist wel. Het hangt ook van je config af etc. Als ik lokaal ga devven en Apache luierd al zeg 10 uur, dan duurt het soms wel 5 sec om het script voor de eerste keer te runnen (swappen etc.). Vuistregel kan zijn: binnen .5 sec is netjes.

Maar eigenlijk zegt het niet zoveel, de load onder normaal/zwaar gebruik is wat je wilt weten..

[Dryw.Filtiarn]

Het gaat om een portal die ontwikkeld word door mijzelf en op het moment zo'n 5 bezoekers max tegelijk heeft en zo'n 100 per dag totaal. Per user word gemiddeld 10 tot 15 keer het betreffende script aangeroepen.
Uiteindelijk is het wel de bedoeling dat deze site groter word en daarbij valt te denken aan een 1000 tot 1500 users per dag.

De huidige server is een PII-350 met 192MB geheugen.

[coubertin119]

Zulke parsetijden zijn echt niet erg hoor.

Total: 0.21 | Incl: 0.05, Init: 0.06, Action: 0.16 | DB: 0.02/20, Tpl: 0.12 | Svr:

Zoveel tijd heeft het bij mij gekost om deze pagina te maken. Best netjes voor zulk 'n druk forum . Maar zolang je 't zelf niet als hinderlijk ervaart is het niet erg. +2.0 seconden is bij mij ook zo'n beetje de grens.

[ACM]

Er zijn imho twee globale redenen om je executietijden laag te houden:
- Reactietijd naar gebruiker "instantaan" aan laten voelen.
- Kortere executietijd is lagere load.

Soms is het niet nodig om kortere tijden te hebben voor het verwerken van de handeling, simpelweg omdat de executietijd bijv maar 5% van de totale wachttijd kost. Toch kan je er dan alsnog naar streven de boel te verkorten, zodat de load op je servers daalt.

Het is dus deels een eigen keuze om de boel te versnellen, en deels service naar je gebruikers.
Imho moet je dat servicedeel onder de 1 seconde (liefst een halve) houden. Maar hoe laag je wilt gaan voor het loaddeel moet je helemaal zelf bepalen ('t kost tenslotte ook een hoop tijd, en dus geld, om het sneller te maken.)

[Config]

Dryw.Filtiarn schreef op 21 maart 2004 @ 19:11:
Het gaat om een portal die ontwikkeld word door mijzelf en op het moment zo'n 5 bezoekers max tegelijk heeft en zo'n 100 per dag totaal. Per user word gemiddeld 10 tot 15 keer het betreffende script aangeroepen.
Uiteindelijk is het wel de bedoeling dat deze site groter word en daarbij valt te denken aan een 1000 tot 1500 users per dag.

De huidige server is een PII-350 met 192MB geheugen.

Alright...

Mijn advies: steek je tijd meer in de portal zelf, het marketen/vullen etc. Of ga werken, of postzegels plakken, of GoT-en, desnoods Fok!en .

Wat ik wil zeggen is dat je dus naar de load moet kijken en niet naar parse times, tenzij ze enorm hoog zijn (3 sec voor de frontpage is best veel). Op het moment dat je load te hoog wordt wordt het misschien tijd voor optimalisatie of hardware upgrades. Wat je wel altijd even moet doen is de PHP Accalerator installen, is binnen 15 min gebeurd (module downloaden en 1 regel in php.ini toevoegen). Daarmee heb ik enorm goede resultaten bereikt (bijv. include files tijd van 600 ms naar 15 ms).

[Verwijderd]

Config schreef op 21 maart 2004 @ 20:15:
[...]
Wat je wel altijd even moet doen is de PHP Accalerator installen, is binnen 15 min gebeurd (module downloaden en 1 regel in php.ini toevoegen). Daarmee heb ik enorm goede resultaten bereikt (bijv. include files tijd van 600 ms naar 15 ms).

Dit klinkt interessant, na wat zoekwerk op google kon ik maar één PHPA vinden, en die is niet voor win32 .

Heeft iemand een linkje naar een PHPA voor win32?

[Brakkie]

Turck mmcache voldoet ook erg goed.

http://turck-mmcache.sourceforge.net/

Is er ook voor windows.

[crisp]

TPL: 0.13 hier onderaan de pagina; dat vind ik zelf al aan de hoge kant, maar komt doordat ik recentelijk extra logica in de list_messages heb gestopt, maar die ik lokaal alweer verbeterd heb
Gouden regel: kijk wat het meest gebruikt wordt, en stop daar je energie in om het te optimaliseren; de rest boeit niet zo.

[Dryw.Filtiarn]

Okee, ik had dus al de Zend Optimizer geinstalleerd, en dat scheelde op zich al wel iets ten opzichte van helemaal geen optimizer geinstalleerd hebben staan, maar om te zeggen dat het verschil zo spectaculair was, nee niet echt. (ZONDER ongeveer 0.19 sec, MET ongeveer 0.17 sec)

Ik heb nu op advies van iemand op een developers IRC kanaal de net genoemde Turck MMCache geinstalleerd en dat scheelt ineens wel behoorlijk. De tijd gaat spontaan terug naar 0.09 sec.

Edit: De genoemde tijden zijn gemiddeldes van 10 script executions!

[ Voor 8% gewijzigd door Dryw.Filtiarn op 21-03-2004 20:56 ]

[MikeN]

Houd er wel rekening mee dat Turck MMCache niet meer wordt geupdate omdat, jawel, de devver daarvan nu bij Zend werkt

[Config]

MikeN schreef op 21 maart 2004 @ 21:02:
Houd er wel rekening mee dat Turck MMCache niet meer wordt geupdate omdat, jawel, de devver daarvan nu bij Zend werkt

Dus het is best een mooie baas .