[PHP] Algehele Optimalisatie...

[Verwijderd]

Momenteel ben ik bezig met een groot CMS systeem en werd bij mij het idee geopperd om algemene classes ook maar in 1 file te drukken via een geautomatiseerd buildsysteem.

Ofwel, voordat je de applicatie afleverd laat je er even een applicatie over heen lopen die alle classes welke benodigd zijn in 1 enkel bestand neerflikkerd en een algemeen bestandje (index.php) die dat bestandje include, class aanmaakt en vervolgens via een standaard interface zijn werk laat doen.

Vervolgens kwam er in mij op dat ik dat idee naar mijn idee al eens eerder had gezien. Toen schoot mij te binnen dat er een forumsysteem is dat gigantische php bestanden meeleverd. Ik zal er niet om heen draaien. Ik heb idd MyReact eens goed bekeken

Nu zijn de bestanden van mijn applicatie ook behandeld door de Zend encoder echter blijfen deze relatief klein. Zou dit nou komen doordat mijn code vele malen kleiner is dan die van chem of toch omdat het idee wat mij eerder werd geopperd blijkbaar toch werkt (Alle klasses in 1 bestand)

Vervolgens maar eens even een benchmark gedraaid en het heeft idd wel iets effect. Alle klasses in 1 bestand is idd iets sneller (nogal wiedus, de schijf hoeft niet allerlei losse bestandjes te zoeken) maar wat ik mij niet kan voorstellen dat dat net de boost is die mijn applicatie zoveel sneller zou moeten maken. Echter wellicht zie ik dit verkeerd

Als chem (+ andere Parse devvers) niet al te boos is dat ik naar het bestandsformaat van MyReact heb gekeken (had ook de reflection API kunnen gebruiken, maar ik respecteer de wensen van Parse ) dan had ik graag gezien dat hij hier zijn mening eens over gaf. Wellicht zelfs even toelichten hoe zij het bij React doen. Lijkt mij op zich niet dat dit een staatsgeheim is

Laat de discussie maar losbarsten

- Flapster

[Verwijderd]

Verwijderd schreef op vrijdag 15 april 2005 @ 10:38:
knip

Vervolgens maar eens even een benchmark gedraaid en het heeft idd wel iets effect. Alle klasses in 1 bestand is idd iets sneller (nogal wiedus, de schijf hoeft niet allerlei losse bestandjes te zoeken) maar wat ik mij niet kan voorstellen dat dat net de boost is die mijn applicatie zoveel sneller zou moeten maken. Echter wellicht zie ik dit verkeerd

Als chem (+ andere Parse devvers) niet al te boos is dat ik naar het bestandsformaat van MyReact heb gekeken (had ook de reflection API kunnen gebruiken, maar ik respecteer de wensen van Parse ) dan had ik graag gezien dat hij hier zijn mening eens over gaf. Wellicht zelfs even toelichten hoe zij het bij React doen. Lijkt mij op zich niet dat dit een staatsgeheim is

Laat de discussie maar losbarsten

- Flapster

Mij lijkt het wel aardig bedrijfsgeheim. Om antwoord te geven op je vraag: alles in een zorgt voor veel betere prestaties als je veel bezoekers krijgt. Bovendien is het een kleine moeite om alles in een bestand te zetten en heeft het zeker geen nadelen.

[mulder]

Ik kan mijzelf niet echt voorstellen dat er voordeel zit aan het includen van 1 grote klasse file. Volgens mij word het onnodig zwaar als je troep include die totaal niet nodig hebt, en denk dat de veiligheid er ook niet beter van word.

[Verwijderd]

Don Facundo schreef op vrijdag 15 april 2005 @ 10:57:
Ik kan mijzelf niet echt voorstellen dat er voordeel zit aan het includen van 1 grote klasse file. Volgens mij word het onnodig zwaar als je troep include die totaal niet nodig hebt, en denk dat de veiligheid er ook niet beter van word.

Je moet ook niet meer includen dan je nodig bent

En hoezo wordt de veiligheid er niet beter op?

[jelmervos]

Don Facundo schreef op vrijdag 15 april 2005 @ 10:57:
Ik kan mijzelf niet echt voorstellen dat er voordeel zit aan het includen van 1 grote klasse file. Volgens mij word het onnodig zwaar als je troep include die totaal niet nodig hebt, en denk dat de veiligheid er ook niet beter van word.

En waarom denk je dat de veiligheid er niet beter van wordt? Argumenten?

[samo]

Volgens mij is dit een deel van wat de Smarty template engine doet: het kopieert de uit te voeren bestanden naar de compile directory, in bruikbare php bestanden, gekoppeld aan de template enz...
(dacht ik toch)

[mulder]

En waarom denk je dat de veiligheid er niet beter van wordt? Argumenten?

je geeft elke pagina toegang tot al je functionliteit.

Je moet ook niet meer includen dan je nodig bent

Je wilt alles in 1 include file, maar alleen includen wat je nodig hebt???

[AtleX]

Besef wel dat een Linux server (Met Windows hosting heb ik geen ervaring) files al snel cached. Open in een geschikte browser maar eens http://www.atlex.nl/, en ga met je muis over het stukje onderaan, tussen de pricacy statement en het copyright. Onthoud even die tijd en refresh de pagina dan eens, soms zie je echt een factor 10 verschil. Dan maakt het niet meer uit dat je include een groot bestand is, het staat toch in de filecache.

Het voordeel van 1 grote file is ook dat je de factor seektime uitschakelt, veel kleine bestandjes openen duurt langer dan 1 groot bestand. Verder heeft het met je veiligheid geen fluit te maken, code die op een bepaalde pagina niet gebruikt wordt vormt ook geen veiligheidsrisico.

[Verwijderd]

Don Facundo schreef op vrijdag 15 april 2005 @ 11:07:
[...]

je geeft elke pagina toegang tot al je functionliteit.

Hier heb je idd wel een punt, maar gezien het feit dat alle bestanden worden ge-encrypt en dat er alleen maar proggers binnen het bedrijf aan werken hoeft dit niet echt een probleem te zijn.

Don Facundo schreef op vrijdag 15 april 2005 @ 11:07:
[...]

Je wilt alles in 1 include file, maar alleen includen wat je nodig hebt???

Je laat een tooltje het originele bestand doorlopen en kijken wat ie allemaal nodig is. Deze stukjes code zoek je op in de .class.php bestanden en plak je er in. Hierna haal je het hele verhaaltje door de zend encoder. Dus je gooit niet lukraak alle classes in 1 bestand. Alleen de klasses die je nodig bent.

Toevoeging: je zou zelfs debug meldingen eruit kunnen filteren en niet op klasse niveau werken maar op functie niveau. Moet zelfs nog beter werken

[ Voor 10% gewijzigd door Verwijderd op 15-04-2005 11:13 ]

[mulder]

Volgens mij begrijp ik niet precies wat je nu wilt, maar ik ben van mening dat code die je niet nodig hebt ook niet geinclude moet worden. Ook in code wil ik alles default 'dicht' en pas 'open' als het nodig is.

Edit: ow ok, ik dacht dat je ALLES in 1 bestand wilde pleuren.

[ Voor 19% gewijzigd door mulder op 15-04-2005 11:14 ]

[Verwijderd]

Alles wat je normaalgesproken include voeg je nu bij de buildfase van je product al in. Je voert dus geen includes meer uit gedurende de uitvoering van het script, maar je knalt de code al van te voren in het bestand.

Sterker nog, je voegt echt alleen de functies toe die je ook daadwerkelijk gebruikt.
Als ik een klasse Core zou hebben met hierin alle algemene functies voor een webapplicatie. Nou gebruikt script X maar 2 functies uit deze klasse maar klasse Core is wel 35 kb. Nou zou je bij een normale include die hele 35 kb moeten includen, parsen enzovoorts.

Als je van te voren de include vervangt met de eigenlijke functies die script X wel echt gebruikt dan hoef je geen 35kb te includen. Echter alleen de 2 functies die daadwerkelijk gebruikt worden.

Ik hoop dat het zo duidelijker is, denken met een lege maag lukt niet zo best

[Verwijderd]

Kaassoevlee schreef op vrijdag 15 april 2005 @ 11:00:
En waarom denk je dat de veiligheid er niet beter van wordt? Argumenten?

Een hele goede opmerking, de vraag die je moet stellen is: "Wat maakt 1 bestand veiliger dan een aantal losse?"

[chem]

Er is op het forum al het eea verteld over onze buildsysteem, dus ik zal enkel vertellen wat al verteld is.

Onze source wordt met een disector tot functie-brokken per class opgehakt. Een post-process script bouwt vervolgens per actie een compleet pakket van elke mogelijke function voor die actie. We gebruiken daar nu nog config files voor, maar mogelijk wordt dat 'ooit' een zelf-lerend systeem.

De voordelen zijn inderdaad een flinke performancewinst. Zeker bij React, waar vaak meerdere servers via rsync communiceren, zijn enkele grote bestanden sneller en beter cachebaar dan vele kleine files.

Wij dumpen dus niet alles op 1 grote hoop, maar maken nog een flinke selectie.

[Verwijderd]

Nou vraag ik me dan toch wel weer af waarom er verscheidene class include bestanden worden bijgeleverd bij React. (Denk aan rights.???, engine.??? en nog meer van die zut)

Als je via die disector alle functies al in je actionclass gooit, waarom zou je deze bestanden dan alsnog meeleveren? Ze zitten dan toch al indirect in je actionclass? Of zie ik dit verkeerd?

[chem]

Er zijn classes die zo zelden gebruikt worden, of na een eerste run niet meer gebruikt worden, of om andere redenen niet geintegreerd worden dat ze beter buiten de main file gelaten kunnen worden.

Alles op 1 hoop gooi is niet zaligmakend - de beste oplossing om je performance te vergroten is om te profilen, testen, benchen en heel, heel veel tijd erin steken.

Er is bijna niets in PHP waar geen sneller alternatief voor is; het is echter de vraag of je je code zo wilt ombuigen, dat performance boven onderhoudbaarheid gaat.

[Verwijderd]

Er is bijna niets in PHP waar geen sneller alternatief voor is

Ligt het aan mij of zeg je nu dat en genoeg snellere alternatieven zijn voor PHP

[Verwijderd]

Verwijderd schreef op zaterdag 16 april 2005 @ 15:22:
[...]


Ligt het aan mij of zeg je nu dat en genoeg snellere alternatieven zijn voor PHP

Ja, dat zegt hij. PHP wordt geinterpreteerd (tenminste ik ken geen native code compiler voor PHP). Geinterpreteerde code is ongeveer 10 keer langzamer dan native code.

[ACM]

Verwijderd schreef op zaterdag 16 april 2005 @ 15:22:
Ligt het aan mij of zeg je nu dat en genoeg snellere alternatieven zijn voor PHP

Nee, hij zegt dat er snellere alternatieven met PHP zijn voor andere PHP-code.

Verwijderd schreef op zaterdag 16 april 2005 @ 16:15:
Ja, dat zegt hij. PHP wordt geinterpreteerd (tenminste ik ken geen native code compiler voor PHP). Geinterpreteerde code is ongeveer 10 keer langzamer dan native code.

Als je voorkomt dat de php-code continu opnieuw geinterpreteerd en gecompileerd moet worden scheelt dat al weer aardig tov de eventuele winsten van een gecompileerde oplossing.
Beide hebben voordelen, bij een geinterpreteerde oplossing zou je runtime profiling data kunnen gebruiken (wat java dus doet) en bij de voorgecompileerde oplossing kan je veel zwaardere analyses op je code loslaten (gcc en icc doen dat bijv)

[ Voor 56% gewijzigd door ACM op 16-04-2005 17:53 ]

[flowerp]

ACM schreef op zaterdag 16 april 2005 @ 17:51:
Beide hebben voordelen, bij een geinterpreteerde oplossing zou je runtime profiling data kunnen gebruiken (wat java dus doet) en bij de voorgecompileerde oplossing kan je veel zwaardere analyses op je code loslaten (gcc en icc doen dat bijv)

De Java compiler doet tegenwoordig helemaal geen optimization meer. Je bytecode (gecompileerde java source, soort hl assembly) is een vrij directe afspiegeling van je source. Alle optimization gaan runtime.

Alle bekende c/cpp compilers doen zware optimization tijdens compilatie (dingen zoals common subexpression elimination, peep hole opt. etc). gcc kan ook beide aanpakken combineren. Door je binary een tijdje in profiling mode te draaien kan de data van het gebruik weer gebruikt worden in de statische analyse. Via tools als Dynamo kun je native binaries net zoals Java en C# dan nogmaals runtime optimizen.

Wat betrefd het van te voren statisch includen wat je nodig hebt (waar het in deze thread voor een groot gedeelte over gaat), dat wordt in velen talen al door de compiler gedaan, dit heet ook wel function inlining. De techniek is al zo oud als de weg naar rome, hoewel compilers er wel steeds beter in worden. In C++ heb je er zelfs een keyword hiervoor om de compiler een hint te geven ( inline ), en MSVC gaat nog een stapje verder hierin.

[ACM]

flowerp schreef op zaterdag 16 april 2005 @ 18:48:
De Java compiler doet tegenwoordig helemaal geen optimization meer. Je bytecode (gecompileerde java source, soort hl assembly) is een vrij directe afspiegeling van je source. Alle optimization gaan runtime.

Dat betwijfel ik. Wordt tegenwoordig zelfs dit (triviale voorbeeld) niet meer geoptimaliseerd: String s = "a" + "b"; naar String s = "ab"; door de compiler zelf?

[Vinnienerd]

Verwijderd schreef op zaterdag 16 april 2005 @ 16:15:
[...]

Ja, dat zegt hij. PHP wordt geinterpreteerd (tenminste ik ken geen native code compiler voor PHP). Geinterpreteerde code is ongeveer 10 keer langzamer dan native code.

Wat dacht je van Zend-encoder?

[Verwijderd]

Vinnienerd schreef op zaterdag 16 april 2005 @ 19:16:
[...]


Wat dacht je van Zend-encoder?

En niet te vergeten:
eAccelerator
http://eaccelerator.net/HomeUk


Wat is een 'disector' ?

[ Voor 8% gewijzigd door Verwijderd op 16-04-2005 19:57 ]

[Verwijderd]

Verwijderd schreef op zaterdag 16 april 2005 @ 19:56:
[...]


En niet te vergeten:
eAccelerator
http://eaccelerator.net/HomeUk

Geen idee, aangezien er geen echte informatie op hun website staat, behalve die paragraaf op de hoofdpagina. Maar dan nog, het lijkt me sterk dat de performance lijkt op die van een echte optimizing compiler.

[ACM]

Het zorgt er voor dat de compilatie-resultaten bewaard blijven en er dus geen tijd verspild wordt om dat elke hit opnieuw te doen. Wij draaien nu met eAccelerator op een paar servers om de stabiliteit en de performance winst te testen en dus is over het algemeen meer dan 10% ten opzichte van een installatie met alleen de zend optimiser.
En de optimalisaties van de Zend Optimiser zorgen voor een aantal compilatie-optimalisaties, welke weet ik niet uit mijn hoofd.

Overigens heb je over het algemeen ook niet echt de performance van een gecompileerde applicatie nodig, vooral omdat een groot deel van je tijd toch gewacht moet worden op je database en dergelijke. Verder heeft php een behoorlijk goede performance als het om string-bewerkingen gaat en juist dat gebruik je bij webapplicaties natuurlijk veel.

[flowerp]

ACM schreef op zaterdag 16 april 2005 @ 18:52:
[...]

Dat betwijfel ik. Wordt tegenwoordig zelfs dit (triviale voorbeeld) niet meer geoptimaliseerd: String s = "a" + "b"; naar String s = "ab"; door de compiler zelf?

De meest simpele dingen worden nog wel gedaan, sommige daarvan zijn idd strikt genomen zeker optimizations. Compilers doen dat soort dingen al jaren zonder dat er een expliciete -O switch voor nodig was.

Nog trivialer voorbeeld:
int i = 1 +3; Dit wordt natuurlijk int i = 4;

Ik kan me overigens voorstellen dat er situaties zijn waarin je wilt dat de compiler niet String s = "a" + "b"; naar String s = "ab"; doet. Namelijk, een string literal wordt "interned" (staat letterlijk als data in je bin in een string pool). Stel dat je dit soort dingen nu heel vaak doet, en a en b komen veel voor, maar ab niet. Neem nu voor a en b een lange string.

Als de compiler de ab optimalisatie doet, zal "ab" interned worden, echter dit zal veel extra geheugen kosten. Space vs time optimization. Mischien dat degene die aan het compilen was juist voor space ging. De compiler weet dit niet.

Daarom zijn compiler optimizations ook bijna altijd flags. Naief zou je zeggen dat iedereen toch altijd de maximale optimization wil, maar zoals je in dit simpele voorbeeld ziet is dat dus niet altijd zo. Javac had ook altijd de expliciete -O flag, maar in 1.4.x en 1.5.x werkt deze niet meer (doet nix).

[flowerp]

ACM schreef op zaterdag 16 april 2005 @ 20:23:
Overigens heb je over het algemeen ook niet echt de performance van een gecompileerde applicatie nodig,

Het hangt een beetje van je toepassing af. Ben je meer met een web applicatie bezig (dwz, eigenlijk bijna een normale applicatie die toevallig een web interface heeft), of gaat het meer richting een web site. In het eerste geval zal eAccelerator en zend zeker wel winst opleveren. Ook in het geval dat je applicatie (of site) om onderhoudbaarheids redenen een sterke (gelayerde) architectuur heeft, dan zal compilatie zeker winst opleveren. (er gaat dan wat cpu tijd verloren aan het doorlopen van de lagen in je architectuur, het bijhouden van administratie, etc).

vooral omdat een groot deel van je tijd toch gewacht moet worden op je database en dergelijke. Verder heeft php een behoorlijk goede performance als het om string-bewerkingen gaat en juist dat gebruik je bij webapplicaties natuurlijk veel.

Klopt ja. Het hangt natuurlijk weer van je applicatie af, maar de meeste web applicaties zijn toch vaak erg DB afhankelijk. Je kunt vaak ook winst behalen door data niet telkens van de DB op te halen, maar gewoon in de user's sessie te zetten. Zeker als je een ingewikkelde querie doet die er meerdere seconden over doet, en je wilt dit resultaat over meerdere pagina's verdelen, dan is het eigenlijk niet te doen of voor elke page de query overnieuw te draaien.

Caching optimalisaties eisen echter meestal ook dat je zelf de cache weer leeg maakt. Je weet niet precies wanneer de user klaar is met het doorlopen van een resultset. Toch kun je niet alles oneindig in het geheugen laten staan.

Ik ben nu zelf bezig met een resultset pool, die door een thread periodiek wordt opgeschoont. Code kan dan de resultset bij deze pool opvragen, en als de resultset er niet (meer) in zit wordt de query overnieuw gedaan.

[bartvb]

Alleen wil je sowieso niet dat je queries hebt die langer dan een tiende seconde nodig hebben om uitgevoerd te worden. Queries die een paar seconde nodig hebben kunnen wel maar dat zijn dan dingen die 1x per dag nodig zijn (b.v. genereren van wat statistieken ofzo) en dan zijn ze niet meer interessant om te cachen.

Het verwijderen van comments, voorkomen van includes, etc, etc, zijn leuk maar maken over het algemeen echt maar een _heel_ erg klein verschil. Al helemaal als je iets als eAccelerator gebruikt en je webserver een OS draait dat na 1985 gereleased is en dus aan file caching doet.

Er valt echt veel meer winst te behalen aan het erg goed bekijken van je database queries (alles dat meer dan 0.05 seconde nodig heeft optimaliseren) en het eens goed doorkijken van je code op zoek naar delen die erg veel gebruikt worden of die erg veel tijd nodig hebben. Eventueel mbv een fatsoenlijke profiler.

Ik heb een paar weken terug naar de Zend profiler gekeken maar dat is voor mij echt een enorm nutteloos ding. Je ziet waar de tijd ongeveer heen gaat maar dat allemaal op een zo hoog nivo dat je geen idee hebt waar je nu het beste kan gaan optimaliseren Als er mensen suggesties hebben voor een profiler die wel nuttige info geeft: graag

[ACM]

flowerp schreef op zondag 17 april 2005 @ 12:38:
Het hangt een beetje van je toepassing af. Ben je meer met een web applicatie bezig (dwz, eigenlijk bijna een normale applicatie die toevallig een web interface heeft), of gaat het meer richting een web site. In het eerste geval zal eAccelerator en zend zeker wel winst opleveren.

Dergelijke oplossingen (eAccelerator, Zend Performance Suite, etc) leveren eigenlijk altijd winst op en aangezien eAccelerator gratis is toe te passen is het dus in wezen gratis winst. Wij hebben nu drie dezelfde servers draaien en degene die is voorzien van eAccelerator heeft gemiddeld genomen zo'n 10% minder tijd nodig per request dan degene met enkel de Zend Optimiser. Degene die is voorzien van Zend Performance Studio heeft overigens weer 10% minder tijd nodig dan eAccelerator... Maar voor de prijs van ZPS (zelfs met flinke korting) voor een dual-cpu machine kan je ook bijna een nieuwe dual-cpu machine kopen en dat levert wel wat meer dan 10% winst op

Caching optimalisaties eisen echter meestal ook dat je zelf de cache weer leeg maakt. Je weet niet precies wanneer de user klaar is met het doorlopen van een resultset. Toch kun je niet alles oneindig in het geheugen laten staan.

Pagina's of delen ervan die eigenlijk altijd hetzelfde zijn maar bijvoorbeeld 20x per dag veranderen kan je op zich natuurlijk heel goed gewoon met een timeout cachen of zelfs pas opnieuw genereren als er wat verandert.

Ik ben nu zelf bezig met een resultset pool, die door een thread periodiek wordt opgeschoont. Code kan dan de resultset bij deze pool opvragen, en als de resultset er niet (meer) in zit wordt de query overnieuw gedaan.

Gelukkig heb ik daar in Java hibernate en ehcache voor, zoiets zelf maken lijkt me best wel rotwerk, maar in php zou ik er overigens geen echte kant en klare oplossingen voor kennen.

[flowerp]

bartvb schreef op zondag 17 april 2005 @ 13:27:
Alleen wil je sowieso niet dat je queries hebt die langer dan een tiende seconde nodig hebben om uitgevoerd te worden.

Dat is een hele narrow minded opvatting!

Dit is ongeveer hetzelfde als dat je zegt dat er geen enkele user applicatie mag zijn dan langer dan een tiende seconde de user laat wachten. De praktijk is anders. Natuurlijk zou ik ook alle data instant ter beschikking willen stellen maar dat kan gewoon niet. Ik snap dat voor veel mensen hun hele programmeer wereld alleen uit het ophalen en displayen van data bestaat. Daar is niks mis mee (natuurlijk niet).

Bedenk echter wel dat er ook klassen van apps zijn (met of zonder web interface) die wel berekeningen op hun data uitvoeren die long running kunnen zijn. In een vorig project was ik bezig met een web applicatie waarbij geologische data in een DB stond, en een user deze icm zelf ingevulde extra data extensief kon analyseren. Alleen in de query tijd kon al makkelijk 20 seconden gaan zitten. Dit was namelijk absoluut geen simpele fetch query, maar bestond uit vele joins en group-by's (om de gegevens voor een bepaalde materiaal soort op te halen, en daar dan weer de materiaal soort eigenschappen uit te halen, etc.). Dit was overigens op een quad xeon bak met 4GB memory.

Daarna kwam nog de patroon analyse (real time, aan de hand van door de onderzoeker ingevoerde parameters). Op de ruwe obvervatie data in de DB werd al elke nacht een pre-processing gedaan (3 grote queries die samen ongeveer 5 uur execution time nodig hadden), dus veel meer viel er absoluut niet van te voren uit te rekenen. Een wetenschapper heeft zelfs nog formeel bewezen dat je niet nog meer van te voren kon uitrekenen, maar dat bewijs kon ik na de eerste twee regels al niet meer volgen

Aangezien een resultset tot wel 2000 rijenen kon bevatten, en je deze niet allemaal tegelijk op het scherm wilde laten weergeven, moesten we wel de resultset cachen. Overnieuw uitrekenen/ophalen was gewoon niet te doen als je alleen maar naar de volgende pagina wilde gaan.

Er zijn velen standaard caching solutions beschikbaar, zowel commercieel als open-source. Commercieel schijnt Coherence een goede te zijn, daarmee kun je zelfs je cache distributed gebruiken en memory inzetten voor je cache van servers die dat geheugen even niet nodig hebben.

[flowerp]

ACM schreef op zondag 17 april 2005 @ 13:52:
[...]

Dergelijke oplossingen (eAccelerator, Zend Performance Suite, etc) leveren eigenlijk altijd winst op en aangezien eAccelerator gratis is toe te passen is het dus in wezen gratis winst.

Heb je gelijk in. Ik bedoelde eigenlijk dat bij de ene situatie de performance winst significant is en bij de andere minder, of niet. Bij niet gaat het dan mischien om een 0.01% winst. Draai je echter zeer hoge volumes (zoals tweakers), dan is zelfs 0.01% winst nog merkbaar als je het bijvoorbeeld maal 1000 neemt.

Pagina's of delen ervan die eigenlijk altijd hetzelfde zijn maar bijvoorbeeld 20x per dag veranderen kan je op zich natuurlijk heel goed gewoon met een timeout cachen of zelfs pas opnieuw genereren als er wat verandert.

In dit geval bedoelde ik een grote resultset die duur was om te bouwen, maar die wel specificiek voor een user is. Deze wil je het liefst even in de sessie van de user opslaan.

Gelukkig heb ik daar in Java hibernate en ehcache voor, zoiets zelf maken lijkt me best wel rotwerk, maar in php zou ik er overigens geen echte kant en klare oplossingen voor kennen.

Het (caching) zou zelfs in de Java standaard komen, draft staat er als sinds 2001 (JCache), maar het loopt blijkbaar nogal uit. Overigens (voor de duidelijkheid voor de andere mensen in deze thread) het is hibernate icm ehcache, hibernate apart is geen caching solutuion maar een o/r mapper.
Zie http://java-source.net/open-source/cache-solutions voor een overzicht van open source caching.

Sommige application servers hebben dit ook standaard. Die van Oracle AS schijnt wel goed te zijn. In PHP heb ik het inderdaad niet kunnen vinden, maar ik neem aan dat het er toch wel voor bestaat?

Ik maak overigens niet het hele caching mechanisme zelf hoor. Alleen een eenvoudig laagje in mijn query manager die kijkt of de resultset in de cache ziet en zo niet de query overnieuw doet. De timeout en size restrictions laat ik over aan de implementatie, ik laat alleen een thread lopen die caches mbt updates invalideerd. En ja, dat is wel een rotwerkje, omdat 1 query van meerdere tables afhankelijk kan zijn: een update in 1 zo'n table invalideerd de resultaten van alle queries die deze table gebruiken. Ik doe het nu heel simpel door de developper zelf een lijstje van afhankelijkheden te laten bijhouden, maar mooier zou zijn als dit dmv SQL parsing automatisch kon gebeuren.

[ACM]

flowerp schreef op zondag 17 april 2005 @ 16:17:
Heb je gelijk in. Ik bedoelde eigenlijk dat bij de ene situatie de performance winst significant is en bij de andere minder, of niet. Bij niet gaat het dan mischien om een 0.01% winst. Draai je echter zeer hoge volumes (zoals tweakers), dan is zelfs 0.01% winst nog merkbaar als je het bijvoorbeeld maal 1000 neemt.

Mja, maar het blijft 0.01% winst
In ons geval zijn de winsten dus zoals gezegd wat groter.

hibernate apart is geen caching solutuion maar een o/r mapper.

Ik doelde op de query-caching van Hibernate, dat het zelf niet cached weet ik, maar het biedt er wel een simpel interfaceje voor

Sommige application servers hebben dit ook standaard. Die van Oracle AS schijnt wel goed te zijn. In PHP heb ik het inderdaad niet kunnen vinden, maar ik neem aan dat het er toch wel voor bestaat?

eAccelerator en consorten bieden shared memory caching, wat vergelijkbaar is met wat je in ehcache kan doen.

De timeout en size restrictions laat ik over aan de implementatie, ik laat alleen een thread lopen die caches mbt updates invalideerd. En ja, dat is wel een rotwerkje, omdat 1 query van meerdere tables afhankelijk kan zijn: een update in 1 zo'n table invalideerd de resultaten van alle queries die deze table gebruiken.

Het zou natuurlijk mooi zijn als Hibernate dit ook al voor je kon doen, maar dat kan het dacht ik nog niet. Ik weet niet of andere O/R-mappers en dergelijke wel een geavanceerdere query-cache kennen.

[bartvb]

Dit is ongeveer hetzelfde als dat je zegt dat er geen enkele user applicatie mag zijn dan langer dan een tiende seconde de user laat wachten.

Klopt. En dat is ook wat ik zeg Ok, een tiende seconde is soms wat krap in sommige applicaties maar als je een publiek beschikbare (web) applicatie hebt dan wil je gewoon niet dat er pagina's zijn die een paar seconde aan CPU nodig hebben, dat is gewoon niet te betalen hardware wise. Maar je hebt zeker wel een punt, soms kom je gewoon niet om cachen heen. Alleen is het wat mij betreft wel een van de laatste opties. Gaan cachen omdat een query 10 seconde nodig heeft is niet echt handig als je geen database hebt met echt miljoenen rows. Als je query zo lang nodig heeft mis je over het algemeen een index of is je database erg gare dingen aan het doen. Als je heel die query helemaal overhoop hebt gehaald en het heeft echt zoveel tijd nodig dan wordt het tijd voor een andere indeling van je database als dit een query is die de gebruiker op een willekeurig tijdstip kan doen. Als je idd pagina's hebt die je DB een seconde of tig vastleggen dan kan iedere loser je site zo plat krijgen. Niet handig en ook niet bepaald een fijne gebruikers ervaring. Ook met cachen zal je gebruiker nog steeds moeten wachten. IMO is dat alleen acceptabel voor queries die slechts een paar keer per dag voorkomen en die de eindgebruiker niet kan doen.

Maar idd, dit is allemaal sterk afhankelijk van je applicatie, ik ging hier voor het gemak even uit van een publiek toegankelijke webapplicatie.

[flowerp]

bartvb schreef op zondag 17 april 2005 @ 18:46:
Maar idd, dit is allemaal sterk afhankelijk van je applicatie, ik ging hier voor het gemak even uit van een publiek toegankelijke webapplicatie.

Het was in mijn geval geen publiek toegankelijke applicatie. Ik geef toe dat je voor websites, en fora actige toepassingen geen langere response tijden dan +- 1 seconden kan tolereren. Je bezoekers haken dan gewoon af. Daar zijn zelfs mooie statistieken van te krijgen op het net. Langer dan 1 seconde, haakt 20% af, langer dan 1.5 30%, bij meer dan 4 seconden 90% oid. (getallen verzin ik even ter plekke, but you get the idea).

Voor echte 'operaties' verwachten de gebruikers wel een langere response tijd. Je moet ze dan wel laten zien dat je wat aan het doen bent kwa processing en dat is nog wel eens lastig in een web omgeving.

Jij verwacht toch ook niet dat als je een mpeg2 movie naar mpeg4 omzet dat dat binnen een tiende van een seconde klaar is? Zo moet je sommige web applicaties ook zien. Eigenlijk zijn het normale applicaties, die alleen remote draaien. In het verleden hadden ze waarschijnlijk een terminal interface gehad, of mischien iets X achtigs, maar vandaag wordt nog als eens gekozen voor een web interface.

Common knowledge zegt dat een applicatie grotendeels onafhankelijk is van de UI (of dat iniedergeval moet zijn ) Als je van een terminal interface naar een web interface gaat betekent dat natuurlijk niet dat je applicatie opeens een factor 1000 sneller moet zijn om nog als bruikbaar te gelden, alleen omdat voor het web de 1 seconden regel geldt.

[chem]

Als je processing > 5 seconden duurt moet je je ook afvragen of je wel een webinterface wil aanbieden.
Mensen hebben een bepaald belevingsbeeld bij het web, en daar hoort de responstijd ook bij. Daarnaast zit je met de standaard timeout van 30 seconden en andere problemen.

Je kan dit oplossen door een wrappertje om een ie.dll te kwakken en toch via het web werken, of een fraaiere oplossing te maken door een SOAP interface te koppelen aan een delphi appje oid.

Daarbij; zo even offtopic - heb je ook gekeken naar andere rdbms'en?

[flowerp]

chem schreef op zondag 17 april 2005 @ 20:21:
Als je processing > 5 seconden duurt moet je je ook afvragen of je wel een webinterface wil aanbieden.

Dat is inderdaad de traditionele beleving, maar je ziet toch dat er echt wel meer soorten applicaties toch met een web interface uitgerust worden. Aan de techniek opzich ligt het niet helemaal (hoewel, voortgang indicators, de back-button, en refreshes kunnen problematisch blijven). Helaas heb je het als 'eenvoudige' programmeur natuurlijk niet altijd voor het zeggen

In dat project probeerden we overigens wel alles zoveel mogelijk op max 4 seconden te houden.

Mensen hebben een bepaald belevingsbeeld bij het web, en daar hoort de responstijd ook bij. Daarnaast zit je met de standaard timeout van 30 seconden en andere problemen.

30 seconden time-out? We hadden een query time-out die op 125 seconden stond, het moest natuurlijk niet te gek worden. De enige browser met een eigen time-out was Safari. Die kapte er na 120 seconden mee.

Je kan dit oplossen door een wrappertje om een ie.dll te kwakken en toch via het web werken, of een fraaiere oplossing te maken door een SOAP interface te koppelen aan een delphi appje oid.

De meeste onderzoekers werkte met Solaris (was standaard van de universiteit) en later ook Linux. Een alternatief had dan eerder een Java applicatie geweest, maar een requirement was dat onderzoekers ook op lokatie gegevens konden invoeren, en op lokatie kon dan ergens in een vreemd land op een publieke computer zijn.

Daarbij; zo even offtopic - heb je ook gekeken naar andere rdbms'en?

Wel aangeraden, maar werd niet gedaan. Men gebruikte Postgresql. Er was alleen mysql geprobeerd, maar voor de soort queries werkte dat niet echt (veel joins, en veel subqueries).