[PHP/ALG] code optimalisatie

[simon]

Ik ben nu bezig met een open-source forum en loop op een aantal punten tegen de 'lamp'.

De lamp van traagheid, eigenlijk. En ik weet het, parse-times zeggen niet alles, maar ik vind 0.1 seconde wel best lang...

Nu is mijn systeem verre van perfect, en zijn mijn tabellen verre van mooi. Maar nu vroeg ik mij af wat doen jullie allemaal om de php code zo snel mogelijk laten draaien?

Wat voor dingen moet ik op letten als ik zo 'goed mogelijk wil coden'?

De source van het forum (incl. sql file) vind je hier:
http://www.tweakers.net/m...ownload_file&file_id=4176

offtopic:
Zo'n topic leek mij handig voor elke php'er, die wat wil optimalizeren, leren we nog wat van elkaar

[Osiris]

offtopic:
Beetje lastig als je de source alleen voor abo's beschikbaar stelt? Of is dat expres?

Misschien moet je Danny en/of Breuls vragen over optimaliseren [/flauw]

Verder zit ik zelf niet zo te kijken naar parse times ed. Ik kijk gewoon hoe snel mijn site bij mezelf laad en zolang dat niet hinderlijk is, is het goed

[GlowMouse]

1) Ik kan niet bij jouw private storage komen
2) Je zult moeten kijken waar de traagheden optreden. Je geeft zelf al aan dat je een slechte database hebt, en dan zou het best kunnen dat het daardoor traag is. Een slecht ontworpen database kan zo tien of honderd keer trager lopen.

[Soultaker]

Gebruik ook de search even; er zijn hier al een aantal topics over geweest.

Simon schreef op 11 maart 2004 @ 21:43:
De source van het forum (incl. sql file) vind je hier:
http://www.tweakers.net/m...ownload_file&file_id=4176

Dat werkt voor mij helaas niet: Private storage is alleen te gebruiken door mensen met een betaald account.

[simon]

Even opnieuw geupped naar: http://www.jackabuzah.com/emp/simon/f30-bb.zip

Osiris schreef op 11 maart 2004 @ 21:45:

offtopic:
Beetje lastig als je de source alleen voor abo's beschikbaar stelt? Of is dat expres?

Misschien moet je Danny en/of Breuls vragen over optimaliseren [/flauw]

Verder zit ik zelf niet zo te kijken naar parse times ed. Ik kijk gewoon hoe snel mijn site bij mezelf laad en zolang dat niet hinderlijk is, is het goed

Hmja, maar stel dat er honderden mensen tegelijk op je site komen, en de boel opeens gaat stressen?

[ Voor 78% gewijzigd door simon op 11-03-2004 21:49 ]

[GlowMouse]

Je hebt helemaal geen indexen in je database! Zie de uitleg in de FAQ. Ik denk dat wanneer je deze goed plaatst, je flinke performancewinst kunt krijgen.

[Grijze Vos]

Een template engine werkt toch met regexps, niet? Daar kan redelijk wat performance in gaan zitten..

[Spider.007]

Ik heb ook de grootste performance winsten gehaald uit het optimaliseren van mijn database. Eerst een wrapper ingeschakeld die alle queries plus runtimes naar een bestand wegschrijft; toen intensief getest en vervolgens de top 10 langste queries geoptimaliseerd.. Snelheidswinsten van meer dan 500%

[.oisyn]

Optimaliseren kun je pas als je weet wat je moet optimaliseren.

Dus... profiling, profiling en nog eens profiling

[gorgi_19]

Simon schreef op 11 maart 2004 @ 21:48:
Hmja, maar stel dat er honderden mensen tegelijk op je site komen, en de boel opeens gaat stressen?

Daar heb je Stress tools voor uitgevonden; deze geven iig een indicatie wat je performance is. Als die er al uitknalt bij een stresstest, kan je er zeker van zijn dat deze in elkaar stort bij een normale load.

[We Are Borg]

gorgi_19 schreef op 11 maart 2004 @ 22:29:
[...]

Daar heb je Stress tools voor uitgevonden; deze geven iig een indicatie wat je performance is. Als die er al uitknalt bij een stresstest, kan je er zeker van zijn dat deze in elkaar stort bij een normale load.

Een stress tool op je php files te testen als in een simulatie van X aantal users die je php file aanspreken ? Heb je daar voorbeelden van?

[Verwijderd]

We Are Borg schreef op 11 maart 2004 @ 22:36:
[...]
Een stress tool op je php files te testen als in een simulatie van X aantal users die je php file aanspreken ? Heb je daar voorbeelden van?

Nee, google vond er bijna geen 1:
http://www.google.nl/sear...F-8&q=stress+tool+php&lr=

[gorgi_19]

We Are Borg schreef op 11 maart 2004 @ 22:36:
[...]


Een stress tool op je php files te testen als in een simulatie van X aantal users die je php file aanspreken ? Heb je daar voorbeelden van?

Microsoft heeft er een gereleased, Microsoft Application Center Test heet het. Ik geloof dat deze ook gratis te downloaden was.

[gomaster]

Ik ben zelf ook bezig met een forum dus ook ff een vraag.
Over indexen gesproken. Ik lees net in de faq dat je dat niet moet doen in tabellen waar veel geinsert en geupdated wordt. Als ik nu een index plaats in de tabel met messages gaat mij dat dan veel performance kosten? Of is het dan verstandig alleen in de tabel met topics een index te zetten? Kortom hoe bepaal je dat dan of het wat opleverd in zo'n geval of niet.

[.oisyn]

.edit: @ gorgi dus

Wat ik overigens een baggertool vind, mind you
Ik had die andere tool van MS waar ik het toen over had weer gevonden gorgi, Web application stress tool dus. Werkt wat handiger dan dat application test center (hoewel je met die laatste waarschijnlijk wel meer dingen kunt doen)

[ Voor 3% gewijzigd door .oisyn op 11-03-2004 22:50 ]

[Soultaker]

Bij Apache zit ook een handig tooltje ab waarmee je handig simpele HTTP requests kan faken.

[djluc]

@gomaster: je zult een afweging moeten maken, meestal is het kleine tijdsverlies bij het inserten en updaten te verwaardelozen tegenover het verlies bij zoeken.

[ACM]

Laten we dan JMeter niet vergeten, heeel erg uitgebreid, maar daardoor ook wel heel nuttig. Denk dat ie kwa complexiteit en functionaliteit wel vergelijkbaar is met Microsoft's tool.

gomaster schreef op 11 maart 2004 @ 22:47:
Ik ben zelf ook bezig met een forum dus ook ff een vraag.
Over indexen gesproken. Ik lees net in de faq dat je dat niet moet doen in tabellen waar veel geinsert en geupdated wordt. Als ik nu een index plaats in de tabel met messages gaat mij dat dan veel performance kosten? Of is het dan verstandig alleen in de tabel met topics een index te zetten? Kortom hoe bepaal je dat dan of het wat opleverd in zo'n geval of niet.

Wellicht dat de FAQ aangepast moet worden
Die passage doelt op het feit dat als er 99 van de 100 queries inserts en updates (ok, misschien al bij 80 van de 100) vs simpele selects dat je dan misschien geen indices moet toepassen... Let op het gebruik van misschien!

Als je snel een kleine subset van je tabel wilt kunnen nemen, en zeker als je dat steeds op ongeveer dezelfde manier doet, moet je daar gewoon indices voor maken. Als je vaak messages uit je messages-tabel trekt aan de hand van het topicid, dan maak je een index op topicid. Userid hetzelfde, etc.

Je kan teveel indices maken, elke index die niet gebruikt wordt is overbodig en moet weg. Elke index die je "later misschien gaat gebruiken" moet je dan maar later maken

[ Voor 73% gewijzigd door ACM op 11-03-2004 23:45 ]

[DiLDoG]

hm weet niet wat je nu gebruikt voor je templates, maar je zou voor de grap eens naar smarty moeten kijken. werkt erg snel en uitgebreid.

[PhoeniX-]

Ik heb voor dance-guide.com veel zitten uitzoeken en testen om de performance te optimaliseren (nog steeds bagger traag, maar dat komt door de shitty shared-hosting bak), en de meeste winst heb ik behaald uit het optimaliseren en toevoegen indices. In dit geval vinden er vele malen meer select queries plaats dan insert/delete dus is 't niet zo erg om indices toe te voegen.

Ander belangrijk punt waar tijdens het programmeren van die site geen rekening was gehouden was dat er niet voor elk nieuwsbericht in de lijst (bijvoorbeeld) de layout opnieuw uit de database hoeft worden gevist ..

Nu istie een stuk sneller

Installatie van php optimizers heeft niet echt veel zin gehad in dit geval .. Zend optimizer leverde een paar procent als ik het goed heb.

[Soultaker]

DiLDoG schreef op 12 maart 2004 @ 09:17:
hm weet niet wat je nu gebruikt voor je templates, maar je zou voor de grap eens naar smarty moeten kijken. werkt erg snel en uitgebreid.

Smarty is zelf geschreven in PHP en waarschijnlijk dus trager dan PHP direct gebruiken. Op zich is dat natuurlijk niet erg als Smarty nuttige functionaliteit toevoegt, maar in een topic over optimalisatie is het misschien niet de meest geschikte suggestie.

[ACM]

Deed smarty niet aan converteren van template-code naar php-code, zodat het op "native snelheid" draait?
Iig doet de template-engine van React dat, met als gevolg dat de overhead van het "parsen" van je templates redelijk beperkt is

[Nielsz]

ACM: klopt.

[Brakkie]

Smarty heeft wel een aantal handige caching functies. Smarty precompiled de templates ook. Misschien zit deze functionaliteit wel niet in de template parser die hij nu gebruikt. Dit levert in ieder geval wel aardige snelheidswinst op ten op zichte van een template parser die deze functionaliteit niet heeft.

edit:

Shit.... Beetje traaaag

[ Voor 7% gewijzigd door Brakkie op 12-03-2004 11:02 ]