[php] optimalisatie

[Meijuh]

Simpele vraag.

Wanneer ik een java bestand compileer met javac dan wordt de code ook geoptimaliseerd.

Wanneer gebeurt dit met php? 1 keer na de eerste keer van het aanroepen van een php bestand, elke keer bij het aanroepen van een php bestand of nooit?

Wanneer loont het zich om de php optimizer van Zend te gebruiken?

[frickY]

PHP is een geinterpreteerde taal. Bij elk request wordt de file van disk gelezen, geparsed, en geïntepreteerd.

Zend Optimizer parsed en inteprereerd het bestand eenmalig, en slaat de byte-code op in een cache-file. Bij executie worden de hele parser en interpreter dus overgeslagen, en kan de byte-code in 1x worden uitgevoerd.

[Meijuh]

dank u

[Frash]

frickY schreef op donderdag 28 mei 2009 @ 21:54:
PHP is een geinterpreteerde taal. Bij elk request wordt de file van disk gelezen, geparsed, en geïntepreteerd.

Zend Optimizer parsed en inteprereerd het bestand eenmalig, en slaat de byte-code op in een cache-file. Bij executie worden de hele parser en interpreter dus overgeslagen, en kan de byte-code in 1x worden uitgevoerd.

Voor zover ik weet optimaliseert die alleen de code.. heb slechte verhalen gehoord over o.a. geheugenlekken en miniem verschil qua performance bij Zend Optimizer. Ik kan je wel xcache (of apc) als opcode cacher aanraden, nooit problemen mee en dikke optimalisaties.

[XWB]

Ik kan je wel xcache (of apc) als opcode cacher aanraden, nooit problemen mee en dikke optimalisaties.

Wij gebruiken ook apc en dat werkt inderdaad erg goed.

[Keiichi]

Voor mijn code heb ik nu alles qua optimizers uitgeprobeerd, maar niets heeft ook maar een miniem merkbaar effect.

Werken die optimizers/cachers wel als PHP onder fastcgi gedraaid word?

[Frash]

Keiichi schreef op zaterdag 30 mei 2009 @ 00:38:
Voor mijn code heb ik nu alles qua optimizers uitgeprobeerd, maar niets heeft ook maar een miniem merkbaar effect.

Werken die optimizers/cachers wel als PHP onder fastcgi gedraaid word?

Ja. Wellicht is je code langzaam. Je kan code profilen met xdebug, hier zijn allerhande compatible IDEs voor en zelfs browser extensies.

[ Voor 20% gewijzigd door Frash op 30-05-2009 09:50 ]

[Keiichi]

Frash schreef op zaterdag 30 mei 2009 @ 09:48:
[...]

Ja. Wellicht is je code langzaam.

Nou, m'n code doet bijna nog niets.

Wordt php langzaam van het gebruik een hoop classes e.d.?

[Woy]

Keiichi schreef op zaterdag 30 mei 2009 @ 14:44:
[...]


Nou, m'n code doet bijna nog niets.

Wordt php langzaam van het gebruik een hoop classes e.d.?

Als je code nog bijna niks doet, valt er natuurlijk ook weinig te optimaliseren. Door een dergelijke tool zul je dan waarschijnlijk alleen minimaal besparen op het parsen van je code.

[Keiichi]

@Frash Ik heb toch even gestoeid met xdebug. Heb uitgevonden dat een MySQL server over een ADSL lijntje niet zo heel snel werkt. Mijn code was het meest gewoon bezig op het wachten op MySQL reacties. De server nu lokaal weggezet en alles vliegt.

Daarna de zendoptimizer weer terug aangezet en nu is het nog eens bijna 2x zo snel

[_JGC_]

Zend Optimizer optimaliseert niks, en moet je alleen gebruiken als je zend encoded bestanden wilt gaan draaien. Opcode cachers zoals xcache, APC of eAccelerator werken veel beter, en maken bij grotere projecten zeker wel verschil. Alhoewel ze voor CGI geen effect hebben, werken ze ook gewoon bij fastcgi, aangezien dan je PHP processen blijven draaien na het parsen en cachen van je php bestanden.

[Frash]

Keiichi schreef op zaterdag 30 mei 2009 @ 16:14:
@Frash Ik heb toch even gestoeid met xdebug. Heb uitgevonden dat een MySQL server over een ADSL lijntje niet zo heel snel werkt. Mijn code was het meest gewoon bezig op het wachten op MySQL reacties. De server nu lokaal weggezet en alles vliegt.

Mooi. Mocht je alsnog die server over WAN/ADSL willen benaderen, gebruik de MYSQL_CLIENT_COMPRESS vlag bij je mysql_connect() functie. Hierdoor wordt er flink in het netwerverkeer gesnoeid ten koste van wat CPU.

[ACM]

Meijuh schreef op donderdag 28 mei 2009 @ 21:27:
Wanneer ik een java bestand compileer met javac dan wordt de code ook geoptimaliseerd.

Dat is overigens niet helemaal de juiste perceptie. Er worden inderdaad simpele optimalisaties uitgevoerd, zoals dat als je "a = 1+1" in je code hebt, dat er dan "a=2" wordt weggeschreven als bytecode, maar heel veel verder dan dat gaat het niet. De meeste optimalisaties komen pas tijdens het draaien van de applicatie aan bod en dan ook van een niveau waar alle PHP-optimizers van verbleken, domweg omdat het in de "run once, throw away everything"-aanpak van PHP al gauw niet meer loont om meer optimalisaties uit te voeren.

Wanneer gebeurt dit met php? 1 keer na de eerste keer van het aanroepen van een php bestand, elke keer bij het aanroepen van een php bestand of nooit?

Dat hangt er dus van af. PHP doet vziw zelf niks van dat soort dingen. Als je alleen een code optimizer zou hebben, zoals iig de Zend Optimizer er een is, dan wordt het bij elke aanroep opnieuw gedaan. Als je daarnaast ook een opcode cacher hebt, dan wordt vziw de geoptimaliseerde code gecached en gebeurt het dus weer maar een keer.
Als je echter een niet-optimaliserende opcode cacher hebt en geen aparte optimizer, dan wordt het weer nooit gedaan.

Wanneer loont het zich om de php optimizer van Zend te gebruiken?

Eigenlijk altijd wel, maar als het kan zijn dat je opcode cacher zelf al wat optimalisaties doet, dan kan het nuttig zijn om geen moeite voor de Zend Optimizer te doen. Ook als je relatief weinig performancewinst ziet en je de extra beheersstappen niet wilt kan het handig zijn.

_JGC_ schreef op zaterdag 30 mei 2009 @ 16:19:
Zend Optimizer optimaliseert niks, en moet je alleen gebruiken als je zend encoded bestanden wilt gaan draaien.

Vziw is dat nog altijd onzin. Zend Optimizer is wel een enorm ondergeschoven kindje geworden, maar vziw biedt het nog steeds diverse niveau's van code-executie-optimalisatie aan. Ik heb geen idee wat er tegenwoordig nog in zit, maar vroeger hadden ze vziw zelfs stukjes loop-unrolling e.d. Uiteraard pusht Zend je nu naar 'Zend Platform' of 'Zend Server', maar vziw leunen ook die weer op de Zend Optimizer en biedt iig de eerste daarnaast een opcode-cacher en mogelijk nog wat meer optimalisatie-lagen.

Opcode cachers zoals xcache, APC of eAccelerator werken veel beter, en maken bij grotere projecten zeker wel verschil.

Ze werken helemaal niet beter dan de Zend Optimizer, ze doen iets heel anders. Ze zorgen er voor dat de code-parsing-stap (en mogelijk nog wat stappen daarna) niet steeds opnieuw uitgevoerd hoeven te worden. eAccelerator biedt daarbij ook nog een code optimizer aan en ook voor xcache zijn ze daar vziw mee bezig.

Alhoewel ze voor CGI geen effect hebben, werken ze ook gewoon bij fastcgi, aangezien dan je PHP processen blijven draaien na het parsen en cachen van je php bestanden.

Er is op zich geen reden waarom ze niet met cgi zouden werken, bijvoorbeeld door de boel in shared memory te stoppen. Wat sowieso ook gebeurt bij dergelijke cachers als ze in php als apachemodule worden gebruikt.

[ Voor 3% gewijzigd door ACM op 31-05-2009 12:20 ]

[_JGC_]

De zend optimizer is een binary module waarvan niet echt duidelijk is wat ie doet (daarnaast crasht ie hier nogal vaak... dmesg staat vol met segfaults in zend optimizer ). Er zijn in het verleden nogal wat benchmarks gedaan met Zend optimizer en zonder zend optimizer, of in combinatie met een opcode cacher, maar meer snelheid werd er niet gehaald met de zend optimizer, soms zelfs trager. Het echte voordeel zit in encoded bestanden, php hoeft die dingen niet meer te parsen en kan ze zo inladen met zend optimizer.

Wat betreft CGI en opcode cachers: APC heb ik geen ervaring mee, eAccelerator werkt met een disk-cache in combinatie met SHM, xcache werkt alleen met SHM. Als je PHP in platte CGI gebruikt, is je PHP proces weg na elke keer een PHP bestand uitvoeren, wat ook betekent dat je SHM weg is. Bij eAccelerator kan de cache evt weer van disk gelezen worden, maar ik vraag me af wat sneller is. Sowieso zit je bij pure CGI niet verlegen om performance denk ik

[Confusion]

ACM schreef op zondag 31 mei 2009 @ 12:18:
Eigenlijk altijd wel, maar als het kan zijn dat je opcode cacher zelf al wat optimalisaties doet, dan kan het nuttig zijn om geen moeite voor de Zend Optimizer te doen. Ook als je relatief weinig performancewinst ziet en je de extra beheersstappen niet wilt kan het handig zijn.

Eigenlijk denk ik dat Meijuh zich voorlopig helemaal niet bezig moet houden met optimalisaties.

@Meijuh: schrijf eerst je software maar eens. Als het dan te traag blijkt te zijn, dan ga je optimaliseren, door eerst te achterhalen waar de traagheid zit. Cachers en optimizers zijn allemaal niet relevant als je code een factor 10 trager is dan nodig. Ze zijn ook niet interessant als het interpreteren van je code een minieme fractie van de totale tijd uitmaakt.

[RobIII]

* RobIII mompelt ook iets van premature optimization en root, evil enzo.

[ACM]

RobIII schreef op zondag 31 mei 2009 @ 13:05:
* RobIII mompelt ook iets van premature optimization en root, evil enzo.

Standaard een opcode-cacher draaien vind ik geen premature optimization.

[RobIII]

ACM schreef op zondag 31 mei 2009 @ 13:21:
[...]

Standaard een opcode-cacher draaien vind ik geen premature optimization.

Nee, dat klopt. Wat ik bedoel te zeggen, en wat confusion ook zegt, is dat 't handiger is om eerst eens aan de gang te gaan en dan te kijken waar de knelpunten zitten en daar iets mee te doen.

[ Voor 3% gewijzigd door RobIII op 31-05-2009 13:26 ]

[_JGC_]

Opcode cachers zijn juist hele nuttige dingen idd. Behalve de omvang van je code kan je helemaal niks veranderen aan de parsetijd van PHP. Optimalisatiemodules zijn dan weer een ander verhaal, maar denk niet dat die modules een dusdanig groot verschil maken dan wat je zelf kunt doen door je code aan te passen.

* _JGC_ mompelt iets over een CMS component die 48% doorbracht in mysql_query, 51% in mysql_fetch_object en 1% andere dingen...
Dankzij een tot in de puntjes getweakte mysql configuratie was bovenstaande nooit opgevallen, en kwam het aan het licht toen een klant dat CMS ging draaien op een niet-getunede dedicated server (waarvan de beheerder weigerde een fatsoenlijke innodb_buffer_pool_size in te stellen omdat hij de standaardwaarden voldoende vond)

[Confusion]

ACM schreef op zondag 31 mei 2009 @ 13:21:
[...]
Standaard een opcode-cacher draaien vind ik geen premature optimization.

Geen enkel PHP project waar ik zijdelings bij betrokken ben wint er iets substantieels bij. Het introduceert alleen extra afhankelijkheden en daarmee risico's. Het is het halve uur om het te installeren en configureren nog niet waard, nog los van het feit dat andere beheerders de kennis missen en het bij eventuele problemen voor hen een extra hindernis vormt. Alleen gebruiken als het substantiele winst oplevert of als je weet dat alle beheerders eventuele problemen moeiteloos op kunnen lossen. Volgens mij is het voor 99 van de 100 commercieel ontwikkelde PHP applicaties de risico's niet waard.

[ Voor 25% gewijzigd door Confusion op 31-05-2009 16:40 ]

[_JGC_]

Daar vergis je je wel behoorlijk in. Bij een request op zich is het niet een noemenswaardig verschil, maar als je website een beetje meer verkeer te verwerken krijgt maakt een opcode cacher weldegelijk een groot verschil.
Zou er niet aan moeten denken om de site van mijn werkgever zonder opcode cacher te draaien. Kan ik beter de coloprovider even bellen om een extra rack en de serverleverancier even bellen om dat rack te vullen met servers voor ik die opcode cacher uitzet.

[Bergen]

Als je een snelle en zeer drukke server hebt, voegt het dan nog wat toe? Laten we GoT als voorbeeld nemen, gebruikt die ook Zend? Of een opcode cacher oid?

[ACM]

Confusion schreef op zondag 31 mei 2009 @ 16:37:
Geen enkel PHP project waar ik zijdelings bij betrokken ben wint er iets substantieels bij.

Wij hebben het standaard aan staan en het levert significante winsten op (binnen de php-executietijd uiteraard). Hoe groter je included files, hoe groter de winst ook zal zijn. Als je altijd precies dat weet in te laden wat je nodig hebt zal de winst allicht minder opvallen.

Het introduceert alleen extra afhankelijkheden en daarmee risico's. Het is het halve uur om het te installeren en configureren nog niet waard, nog los van het feit dat andere beheerders de kennis missen en het bij eventuele problemen voor hen een extra hindernis vormt.

Het introduceert helemaal geen afhankelijkheden, maar je hebt uiteraard wel een extra component dat voor problemen in php kan zorgen. Zodra je kunt kiezen tussen een dergelijke (gratis) opcode-cacher of een nieuwe server dan wordt de keus helemaal makkelijk, want dat is het soort winst dat je er mee kan boeken.

Alleen gebruiken als het substantiele winst oplevert of als je weet dat alle beheerders eventuele problemen moeiteloos op kunnen lossen. Volgens mij is het voor 99 van de 100 commercieel ontwikkelde PHP applicaties de risico's niet waard.

Ik snap deze opmerking niet. De beheerder is juist degene die kiest of er wel of niet een opcode-cacher komt te draaien, tenzij je het nu ineens weer over de Zend Optimizer hebt en het aanleveren van encoded content?

Bergen schreef op zondag 31 mei 2009 @ 17:53:
Als je een snelle en zeer drukke server hebt, voegt het dan nog wat toe? Laten we GoT als voorbeeld nemen, gebruikt die ook Zend? Of een opcode cacher oid?

Wij hebben wel eens twee identieke servers met en zonder opcode cacher (eAccelerator) gedraaid, ik weet de getallen niet meer, maar de verschillen waren aardig groot. Sindsdien draaien we standaard met eAccelerator
Zodra we weer een keer nieuwe kopen wil ik zoiets weer opnieuw bekijken.

[Confusion]

_JGC_ schreef op zondag 31 mei 2009 @ 17:07:
Daar vergis je je wel behoorlijk in.

Ik betwijfel dat jij de toegevoegde waarde van een opcode cacher voor de projecten waar ik bij betrokken ben beter kan inschatten dan ik . Als de enige zorgen responsetijden zijn en het grootste deel van de tijd wordt besteedt aan het wachten op resultaten van queries, dan heb je niets aan een opcode cacher. Applicaties kunnen best 150K kosten en ondertussen op een PIII draaien, waarvan ze de CPU lang niet voltrekken, omdat het zware werk elders word verricht.

ACM schreef op zondag 31 mei 2009 @ 20:43:
Het introduceert helemaal geen afhankelijkheden

Je bent afhankelijk van de opcode cacher en zijn configuratie. Als ik een PHP applicatie oplever, dan ga ik niet standaard de xcache .deb installeren, omdat dat een extra manier is waarop de applicatie kan falen bij de volgende aptitude upgrade. Er moet voor ieder package voldoende reden zijn om het te installeren en die is er bij xcache tot nog toe nooit geweest.

Zodra je kunt kiezen tussen een dergelijke (gratis) opcode-cacher of een nieuwe server dan wordt de keus helemaal makkelijk, want dat is het soort winst dat je er mee kan boeken.

Dat soort afwegingen speelt bij 99 van de 100 applicaties helemaal niet. Sommigen zouden het willen, maar vaak zelfs dat niet. Er wordt in dit soort discussies te vaak gefocussed op de casus 'grote website', terwijl die een minieme fractie van alle projecten uitmaakt.

Ik snap deze opmerking niet. De beheerder is juist degene die kiest of er wel of niet een opcode-cacher komt te draaien

De beheerder is degene die een applicatie met afhankelijkheden overgedragen krijgt. Hoe simpeler, hoe beter. Als ik mod-rewrite weg kan laten, dan laat ik die ook weg.

[ Voor 52% gewijzigd door Confusion op 31-05-2009 20:57 ]

[Patriot]

Confusion schreef op zondag 31 mei 2009 @ 20:47:
[...]

Ik betwijfel dat jij de toegevoegde waarde van een opcode cacher voor de projecten waar ik bij betrokken ben beter kan inschatten dan ik .

Ik denk dat hij doelde op je stelling dat 99% van alle commerciele projecten geen baat zou hebben bij het gebruiken van zo'n opcode cacher

Als de enige zorgen responsetijden zijn en het grootste deel van de tijd wordt besteedt aan het wachten op resultaten van queries, dan heb je niets aan een opcode cacher.

Hoezo 'niets'? Omdat je de grootste tijdvreter niet aanpakt? Het geheel is toch sneller, dat is toch het uiteindelijke punt?

Applicaties kunnen best 150K kosten en ondertussen op een PIII draaien, waarvan ze de CPU lang niet voltrekken, omdat het zware werk elders word verricht.

Het scheelt instructies, op een tragere server is de absolute tijdwinst dus groter.

EDIT:
Overigens vind ik sowieso dat je de risico's die zoiets met zich meebrengt een beetje overdrijft.

[ Voor 5% gewijzigd door Patriot op 31-05-2009 21:29 ]

[_JGC_]

Het is ook maar net waar je het voor gebruikt. Gebruik je het voor een webserver die veel pagina's gaat serveren, dan heeft het zin. Gebruik je het om een script te optimaliseren dat 2x per uur een minuut of 10 draait, dan is het de meest doelloze optimalisatie die er bestaat.
Verder kunnen bepaalde opcode cachers wel degelijk problemen geven. Ik heb met APC crashes gezien, heb met eAccelerator wel crashes gezien, met xcache nog niet maar zullen er vast ook wel zijn. Mijn werkgever gebruikte voorheen ionCube php accelerator. Qua snelheid werkt dat ding goed, maar het wordt niet meer ontwikkeld, ondersteunt geen php5, is een gore binary module en doet soms optimalisaties die het niet hoort te doen. Ja soms... bepaalde dingen zoals 2x dezelfde class includen wordt gewoon compleet genegeerd, maar soms ook niet, waardoor je vreemde onreproduceerbare fouten krijgt. Bijkomend nadeel is dat je code dan ook totaal niet uitwisselbaar is met andere php configuraties.

[Confusion]

Patriot schreef op zondag 31 mei 2009 @ 21:27:
Ik denk dat hij doelde op je stelling dat 99% van alle commerciele projecten geen baat zou hebben bij het gebruiken van zo'n opcode cacher

Tjah, de meeste projecten zijn nu eenmaal geen high traffic websites. Ga maar na: hoeveel kleine administratieve applicaties, front-ends, etc. zijn er in de wereld actief tegenover hoeveel PHP websites met zoveel verkeer dat ze meer dan 1 moderne server voltrekken? Omdat functionaliteiten fysiek worden gescheiden zijn servers vaak ook nog hopeloos onderbezet, waardoor het ook niet uitmaakt of ze desnoods 90% minder verbruiken.

Hoezo 'niets'? Omdat je de grootste tijdvreter niet aanpakt? Het geheel is toch sneller, dat is toch het uiteindelijke punt?

Als servers niet relevant zijn, is het enige dat telt de gebruikerservaring. Als de responsetijden onder pakweg 200 ms zitten, dan heeft het geen zin daar nog iets af te schaven (zelfs al reduceer je het tot 50 ms): gebruikers merken het verschil niet. Als de responsetijden boven de pakweg 1500 ms zitten, dan geldt precies hetzelfde.

Overigens vind ik sowieso dat je de risico's die zoiets met zich meebrengt een beetje overdrijft.

Ik vond dat ook tot een schijnbaar onschuldige upgrade een keer een site om zeep hielp en ik me realiseerde hoezeer mijn paranoide collega eigenlijk niet paranoide was, maar gewoon gezond voorzichtig. Ieder extra package is er 1 die een security issue kan bevatten, stuk kan gaan bij een upgrade of een onvoorziene afhankelijkheid op een ander package kan hebben, waardoor je naar een speld in een hooiberg zoekt als er iets stuk gaat.

[Patriot]

Confusion schreef op zondag 31 mei 2009 @ 22:53:
[...]

Tjah, de meeste projecten zijn nu eenmaal geen high traffic websites. Ga maar na: hoeveel kleine administratieve applicaties, front-ends, etc. zijn er in de wereld actief tegenover hoeveel PHP websites met zoveel verkeer dat ze meer dan 1 moderne server voltrekken? Omdat functionaliteiten fysiek worden gescheiden zijn servers vaak ook nog hopeloos onderbezet, waardoor het ook niet uitmaakt of ze desnoods 90% minder verbruiken.

Ik wilde je er dan ook alleen op wijzen dat hij het niet over jouw ervaring met je eigen projecten had.

[...]

Als servers niet relevant zijn, is het enige dat telt de gebruikerservaring. Als de responsetijden onder pakweg 200 ms zitten, dan heeft het geen zin daar nog iets af te schaven (zelfs al reduceer je het tot 50 ms): gebruikers merken het verschil niet. Als de responsetijden boven de pakweg 1500 ms zitten, dan geldt precies hetzelfde.

Helaas kun je in de praktijk niet garanderen dat alle gebruikers met dezelfde responsetijden te maken zullen krijgen. Een slechte verbinding of een grotere fysieke (of relatieve) afstand met de server heeft ook zijn invloeden op die responsetijd. Door maatregelen te nemen om die responsetijd bij de server te verlagen, kunnen mensen die een responsetijd hebben die boven het gemiddelde ligt op die manier weer binnen de grenzen komen.

[...]

Ik vond dat ook tot een schijnbaar onschuldige upgrade een keer een site om zeep hielp en ik me realiseerde hoezeer mijn paranoide collega eigenlijk niet paranoide was, maar gewoon gezond voorzichtig. Ieder extra package is er 1 die een security issue kan bevatten, stuk kan gaan bij een upgrade of een onvoorziene afhankelijkheid op een ander package kan hebben, waardoor je naar een speld in een hooiberg zoekt als er iets stuk gaat.

Ho ho ho. Ik zeg niet dat het verstandig is om maar te pas en te onpas packages te installeren op je server. Ik zeg alleen dat je de risico's overdrijft. Je doet alsof een probleem met een package eerder regel is dan uitzondering, en bovendien doe je alsof ieder probleem dat ontstaat van systeemvernietigende aard is (ok, nu overdrijf ik ook, maar mijn punt is hopelijk duidelijk).

[ACM]

Confusion schreef op zondag 31 mei 2009 @ 20:47:
Je bent afhankelijk van de opcode cacher en zijn configuratie. Als ik een PHP applicatie oplever, dan ga ik niet standaard de xcache .deb installeren, omdat dat een extra manier is waarop de applicatie kan falen bij de volgende aptitude upgrade. Er moet voor ieder package voldoende reden zijn om het te installeren en die is er bij xcache tot nog toe nooit geweest.

Tenzij jij iets anders doet met een opcode cacher dan opcode cachen heb je geen dependency erop. Je kiest er voor om dat ding aan te zetten, en de performance verbeterd, of niet en dan is er niks aan de hand. Als je ook de in-process cache ervan gaat gebruiken, ja, dan introduceer je een afhankelijkheid... Maar daar had ik het dan ook niet over.
Als jij een applicatie oplevert die alleen goed werkt met een specifieke opcode cacher, dan wordt het inderdaad een afhankelijkheid die extra configuratie vereist. Als jij enkel de applicatie oplevert met als performancetip om een opcode cacher te installeren, dan laat je die keus volledig vrij aan de beheerder van die site.

Dat soort afwegingen speelt bij 99 van de 100 applicaties helemaal niet. Sommigen zouden het willen, maar vaak zelfs dat niet. Er wordt in dit soort discussies te vaak gefocussed op de casus 'grote website', terwijl die een minieme fractie van alle projecten uitmaakt.

Tegelijk draaien de kleine websites vaak op relatief heel lichte, of gedeelde servers, waardoor het wederom weer nut kan hebben om er aandacht aan te besteden.

De beheerder is degene die een applicatie met afhankelijkheden overgedragen krijgt. Hoe simpeler, hoe beter. Als ik mod-rewrite weg kan laten, dan laat ik die ook weg.

Waarom heb je het toch steeds over afhankelijkheden? Een opcode cacher is transparant, de werking van de gecachte scripts wordt niet beinvloed door de opcode cacher. Pas als je de code zo gaat schrijven dat je gebruik maakt van de, meestal ook geintegreerde, shared memory object cache introduceer je een afhankelijkheid.

[Mr_Light]

Hebben ze hier bij tweakers wel eens quercus gedraaid?
http://caucho.com/resin/doc/quercus.xtp#apc_module

Was het nu net zo snel als met gebruikelijkere setup en opcode cache?
Was er nu echt nog wat mee te doen met van wat een java profiler uitspuugt of is dat een wassen neus?

[ACM]

Mr_Light schreef op maandag 01 juni 2009 @ 00:27:
Hebben ze hier bij tweakers wel eens quercus gedraaid?
http://caucho.com/resin/doc/quercus.xtp#apc_module

Nee.

Was het nu net zo snel als met gebruikelijkere setup en opcode cache?

Geen idee dus

Was er nu echt nog wat mee te doen met van wat een java profiler uitspuugt of is dat een wassen neus?

Het grootste nadeel van (java) profilers vind ik, is dat ze een verkeerd beeld geven van waar de tijd in gaat zitten. Doordat ze triviale functies ook voorzien van profiling-calls worden die onevenredig zwaar, helemaal omdat de hotspot-optimizer van Java die functie-aanroepen juist compleet zou hebben weggeoptimaliseerd.
Met xdebug geldt iets soortgelijks, want ook daar geldt natuurlijk dat de profiling-per-functie-call min of meer constante tijd kost, maar dat niet elke functie evenveel tijd kost, en dus de profiling relatief zwaar is voor de trivialere calls.

[Frash]

Confusion schreef op zondag 31 mei 2009 @ 22:53:
Ik vond dat ook tot een schijnbaar onschuldige upgrade een keer een site om zeep hielp en ik me realiseerde hoezeer mijn paranoide collega eigenlijk niet paranoide was, maar gewoon gezond voorzichtig. Ieder extra package is er 1 die een security issue kan bevatten, stuk kan gaan bij een upgrade of een onvoorziene afhankelijkheid op een ander package kan hebben, waardoor je naar een speld in een hooiberg zoekt als er iets stuk gaat.

Waarom compileer je dan niet gewoon zelf? Ben je niet afhankelijk van packagebeheerders, kun je CPU-specifieke optimalisaties (en configure args) erin gooien en kun je bij veiligheidsprobleem adequaat handelen. Update is dan nieuwe tarball wgetten, configure regel uit config.log/configure.status halen, make, make install en klaar. Kost je 5 minuten incl Senseotje.

Voor (systeem) libraries en eenvoudige (weinig modulaire) dingen als FTP servers ben ik gek op Aptitude, maar voor Webserver/PHP is het me toch echt te inflexibel. Aptitude is mooi maar het moet niet zo zijn dat je niet meer zonder kan imho.

[Mr_Light]

ACM schreef op maandag 01 juni 2009 @ 10:28:
[...]

Nee.


[...]

Geen idee dus


[...]

Het grootste nadeel van (java) profilers vind ik, is dat ze een verkeerd beeld geven van waar de tijd in gaat zitten. Doordat ze triviale functies ook voorzien van profiling-calls worden die onevenredig zwaar, helemaal omdat de hotspot-optimizer van Java die functie-aanroepen juist compleet zou hebben weggeoptimaliseerd.
Met xdebug geldt iets soortgelijks, want ook daar geldt natuurlijk dat de profiling-per-functie-call min of meer constante tijd kost, maar dat niet elke functie evenveel tijd kost, en dus de profiling relatief zwaar is voor de trivialere calls.

Lies, damn lies and statistics - kwestie van de gegevens juist interpreteren en je profiler wat afstellen filteren. Als het zo simpel was dat we alleen maar op de knop hoeven te drukken hebben we als it-ers geen bestaansrecht meer toch?

[.oisyn]

ACM schreef op maandag 01 juni 2009 @ 10:28:
Het grootste nadeel van (java) profilers vind ik, is dat ze een verkeerd beeld geven van waar de tijd in gaat zitten. Doordat ze triviale functies ook voorzien van profiling-calls worden die onevenredig zwaar, helemaal omdat de hotspot-optimizer van Java die functie-aanroepen juist compleet zou hebben weggeoptimaliseerd.

WTF? Wat heb je dan nog aan een profiler, als deze ervoor zorgt dat de code niet op dezelfde manier gerund wordt? Sowieso, 'profiling calls'? Heb je niet gewoon sampling based profilers voor Java? Of profilers die gebruik kunnen maken van de instrumentation features van de onderliggende CPU, waardoor er dus ook geen code aangepast hoeft te worden? Is er geen VTune (Intel) of CodeAnalyst (AMD) voor Java?

[Mr_Light]

alles heeft invloed, alles wat draait, gezien elk ander proces op een of andere manier resources claimt en re-ordering altijd aan de orde van de dag is. De uitvoer word altijd beïnvloed tenzij je daadwerkelijk hardware ondersteuning pakt. Wat heb je dan nog aan een profiler, als deze ervoor zorgt dat de code niet op dezelfde manier gerund wordt?

Wat heb je dan nog aan een profiler, als deze ervoor zorgt dat de code niet op dezelfde manier gerund wordt?

klinkt als of je een utopie nastreeft. Als we het beide gewoon over geen "significante impact" zou moeten hebben, heb ik niets gezegd.

Sampling based en vtune/codeanalist support is er allemaal maar dat geeft andere inzicht en/of in andere dingen. Profiling calls worden of in de bytecode geinject of helemaal at runtime toegevoegd 'de code' word niet aangepast.

En zelfs wanneer en meting invloed heeft op wat gemeten word kan het nog altijd bruikbare data opleveren

[ Voor 6% gewijzigd door Mr_Light op 02-06-2009 01:32 ]

[.oisyn]

Mr_Light schreef op dinsdag 02 juni 2009 @ 01:29:
alles heeft invloed, alles wat draait, gezien elk ander proces op een of andere manier resources claimt en re-ordering altijd aan de orde van de dag is.

Big fuckin "DUH"

klinkt als of je een utopie nastreeft. Als we het beide gewoon over geen "significante impact" zou moeten hebben, heb ik niets gezegd.

Ik heb het idd over een significante impact. ACM had het erover dat kleine functies bovenin je resultaten terecht komen. Dit is iets wat met een goede profiler niet mag gebeuren. Natuurlijk zal een profiler altijd je metingen beïnvloeden, maar zolang hij alles evenveel beïnvloedt maakt dat niet meer uit. Als je app echter met profiler in een keer 50% van z'n tijd in getters blijkt te zitten, terwijl die getters normaal gesproken compleet weggeoptimaliseerd worden dan moet je je nog eens achter je oren gaan krabben of je op dat moment wel een goede profiler gebruikt.

Profiling calls worden of in de bytecode geinject of helemaal at runtime toegevoegd 'de code' word niet aangepast.

De code wordt dus wel aangepast - ik had het over de uiteindelijke output van de JITer.

[Mr_Light]

.oisyn schreef op dinsdag 02 juni 2009 @ 01:51:
[...]

Big fuckin "DUH"

safe harbour statement

[...]
...dan moet je je nog eens achter je oren gaan krabben of je op dat moment wel een goede profiler gebruikt. je profiler goed hebt afgesteld.

[...]
De code wordt dus wel aangepast - ik had het over de uiteindelijke output van de JITer.

ja, alhoewel in het voorbeeld wat nu aangedragen word, die timing instructies echt geen inlining in de weg gaat staan. Het probleem is volgens mij niet dat de optimalisaties zouden worden tegengehouden, maar dat verhoudingsgewijs de timing instructie veel tijd kost in verhouding met de tijd die het kost om die methode uit te voeren, als deze dan ook nog eens ontzettend veel word aangeroepen word dat effect erg versterkt. Wat tot een mis-representatie leid van die method en z'n relatieve impact. In other 'news'...

meuh gewoon filteren uit je 'te instrumenteren methodes'

[raptorix]

Als performance een issue wordt zou ik uberhaupt geen PHP gebruiken, ik snap sowieso niet waarom mensen nog steeds PHP gebruiken.

[Bergen]

raptorix schreef op dinsdag 02 juni 2009 @ 10:26:
Als performance een issue wordt zou ik uberhaupt geen PHP gebruiken, ik snap sowieso niet waarom mensen nog steeds PHP gebruiken.

GoT draait toch ook vlot op PHP? En als ik me niet vergis hebben de servers waar dit forum op draait het aardig druk. Of kun je dan stellen dat performance hier geen issue is?

[ Voor 23% gewijzigd door Bergen op 02-06-2009 10:39 ]

[Keiichi]

PHP is natuurlijk wel wat zwaarder dan een applicatie geprogrammeerd in C(++)

Maar ik zou er niet aan moeten denken om bepaalde webpagina's van mij van PHP af te halen en te programmeren in C(++). Daar ben ik onevenredig veel tijd mee kwijt.

Wellicht dat de snelheid van programmeren en debuggen opweegt tegen de performance

[raptorix]

Bergen schreef op dinsdag 02 juni 2009 @ 10:30:
[...]
GoT draait toch ook vlot op PHP? En als ik me niet vergis hebben de servers waar dit forum op draait het aardig druk. Of kun je dan stellen dat performance hier geen issue is?

Er zijn ook Ladas die 250 kilometer per uur kunnen, maar om nou te roepen dat Lada een geschikte sportwagen is, is wat overdreven.

[.oisyn]

Keiichi schreef op dinsdag 02 juni 2009 @ 10:57:
Maar ik zou er niet aan moeten denken om bepaalde webpagina's van mij van PHP af te halen en te programmeren in C(++). Daar ben ik onevenredig veel tijd mee kwijt.

Jij misschien

Wellicht dat de snelheid van programmeren en debuggen opweegt tegen de performance

In mijn ervaring is C++ debuggen anders een stuk makkelijker dan PHP debuggen.

[raptorix]

Keiichi schreef op dinsdag 02 juni 2009 @ 10:57:
PHP is natuurlijk wel wat zwaarder dan een applicatie geprogrammeerd in C(++)

Maar ik zou er niet aan moeten denken om bepaalde webpagina's van mij van PHP af te halen en te programmeren in C(++). Daar ben ik onevenredig veel tijd mee kwijt.

Wellicht dat de snelheid van programmeren en debuggen opweegt tegen de performance

Wel eens gehoord dat er ook talen als C# en Java zijn?

[Keiichi]

.oisyn schreef op dinsdag 02 juni 2009 @ 11:09:
[...]
Jij misschien
[...]

In mijn ervaring is C++ debuggen anders een stuk makkelijker dan PHP debuggen.

Mijn ervaring op C++ is nog niet zo groot, maar ik ga me er binnenkort wel aan wagen om iets voor de proef om te bouwen van PHP naar C++

raptorix schreef op dinsdag 02 juni 2009 @ 11:10:
[...]
Wel eens gehoord dat er ook talen als C# en Java zijn?

Ik heb eigenlijk nog nooit van iemand gehoord dat Java effcienter dan PHP is. Mijn ervaringen met Java bevestigen dit wel iets

[YopY]

D'r is geen reden om nu ineens PHP te gaan trollen ten faveure van andere talen in dit topic. PHP kan heel performant zijn (waar ook dit topic over gaat), mits je er goed mee om kunt gaan. D'r is geen reden om nu alsnog de zoveelste PHP vs Java vs C# discussie te starten. Dat taal X mogelijk sneller kan zijn dan taal Y betekent niet dat taal X geschikter is voor een taak

[ACM]

.oisyn schreef op maandag 01 juni 2009 @ 22:48:
WTF? Wat heb je dan nog aan een profiler, als deze ervoor zorgt dat de code niet op dezelfde manier gerund wordt? Sowieso, 'profiling calls'? Heb je niet gewoon sampling based profilers voor Java? Of profilers die gebruik kunnen maken van de instrumentation features van de onderliggende CPU, waardoor er dus ook geen code aangepast hoeft te worden? Is er geen VTune (Intel) of CodeAnalyst (AMD) voor Java?

Niet iedereen is even ervaren met het gebruik van profilers als jij. Dus je kan wel verbaasde uitroepen doen, maar als je bijv even snel met 'jvisualvm' wilt kijken wat je applicatie doet, dan loop je tegen bovenstaand probleem op.
Met geavanceerdere profilers kan er vast meer, maar dan moet je ook al gauw diep in de buidel tasten en/of flink meer tijd aan je profiling besteden. Zoals je vast wel had geraden ondertussen heb ik zelf ook niet enorm veel ervaring met profilers. Ik heb doorgaans niet het soort code voor mijn neus waar een geavanceerde profiler de enige manier is om meer duidelijkheid te krijgen over waar de tijd van je applicatie aan besteed wordt

[.oisyn]

Tja, ik ben idd verwend met tools zoals Performance Investigator for Xbox (PIX), die van een run letterlijk elke instructie kan recorden, wat vervolgens op de PC wordt geanalyseerd dmv simulatie zodat daarna precies bekend is waar alle potentiele stalls (cache misses, jump mispredictions, etc.) zitten en hoe duur stukken code zijn, zonder dat de profiling zelf er ook maar enige invloed op heeft

[ Voor 5% gewijzigd door .oisyn op 02-06-2009 12:20 ]

[raptorix]

Keiichi schreef op dinsdag 02 juni 2009 @ 11:18:
[...]


Mijn ervaring op C++ is nog niet zo groot, maar ik ga me er binnenkort wel aan wagen om iets voor de proef om te bouwen van PHP naar C++


[...]


Ik heb eigenlijk nog nooit van iemand gehoord dat Java effcienter dan PHP is. Mijn ervaringen met Java bevestigen dit wel iets

Het ging hier over optimalisatie, ik wil PHP als taal niet trollen, maar als je PHP niet performed dan is het eigenlijk al niet de juiste tool. PHP is prima geschikt als webtaal om bijvoorbeeld content te tonen, maar minder geschikt voor zware processen. Overigens is web performance zwaar overrated, je meot wel hele rare dingen doen wil je taal daar de bottle neck zijn, in vergelijking met de SQL overhead valt je script performance in het niet.

[_JGC_]

Ik heb zelf webontwikkeling in zowel VB.Net als PHP gedaan, en ik kan niet bepaald zeggen dat ontwikkelen met het .Net platform snellere code oplevert dan PHP. Wat omgevingen zoals .Net en Java vooral als voordeel hebben is dat je de code eenmaal compileert, en daarna net zolang blijft draaien totdat je server gekilld/gecrasht/gestopt wordt. Bij PHP met een opcode cacher is dit niet anders.
Het grootste deel van de tijd wordt doorgebracht in het lezen van disk of database en het sturen van rommel naar de client, ik heb niet het idee dat de minimale winst die je haalt uit JIT-compilers daar veel invloed op hebben.

[raptorix]

_JGC_ schreef op dinsdag 02 juni 2009 @ 12:53:
Ik heb zelf webontwikkeling in zowel VB.Net als PHP gedaan, en ik kan niet bepaald zeggen dat ontwikkelen met het .Net platform snellere code oplevert dan PHP. Wat omgevingen zoals .Net en Java vooral als voordeel hebben is dat je de code eenmaal compileert, en daarna net zolang blijft draaien totdat je server gekilld/gecrasht/gestopt wordt. Bij PHP met een opcode cacher is dit niet anders.
Het grootste deel van de tijd wordt doorgebracht in het lezen van disk of database en het sturen van rommel naar de client, ik heb niet het idee dat de minimale winst die je haalt uit JIT-compilers daar veel invloed op hebben.

Nog een Jan Doedel die het over "snellere" code heeft, nogmaals geef me 1 voorbeeld van een webapplicatie waarbij de snelheid van je code echt van relevant belang was?

[_JGC_]

raptorix schreef op dinsdag 02 juni 2009 @ 13:15:
[...]

Nog een Jan Doedel die het over "snellere" code heeft, nogmaals geef me 1 voorbeeld van een webapplicatie waarbij de snelheid van je code echt van relevant belang was?

Deze Jan Doedel kan tenminste lezen. Lees de hele reactie eens door voor je dit soort botte opmerkingen plaatst.

[ACM]

raptorix schreef op dinsdag 02 juni 2009 @ 13:15:
Nog een Jan Doedel die het over "snellere" code heeft, nogmaals geef me 1 voorbeeld van een webapplicatie waarbij de snelheid van je code echt van relevant belang was?

Het hangt uiteraard van de toepassing, de schaalgrootte vs je servers etc af. Maar bij ons werd het grootst deel van de verwerking van de data voor de pricewatchcategorieen in PHP-code uitgevoerd. En dan is het echt wel van belang dat je zowel op indirecte (bijv via geheugengebruik/objectgroottes) als directe performance let. Ik heb daar iig de code al kwa performance teruggebracht van de eerste "werkende versie" die zo'n lijst met een paar duizend objecten in vele seconden, naar maximaal een seconde weten terug te brengen.

En dan kan je wel met dooddoeners gooien dat "php dan niet de geschikte taal is", maar op het moment dat je al met een platform werkt is het niet bepaald triviaal om zomaar ineens over te stappen naar een andere. Het is echt niet onmogelijk om met wat efficient gebruik van caches en cronjobs er voor te zorgen dat zelfs zeer process-intensieve taken ook met PHP in een webapplicatie te integreren zijn.

[ Voor 9% gewijzigd door ACM op 02-06-2009 14:08 ]

[Keiichi]

raptorix schreef op dinsdag 02 juni 2009 @ 12:33:
[...]

Het ging hier over optimalisatie, ik wil PHP als taal niet trollen, maar als je PHP niet performed dan is het eigenlijk al niet de juiste tool. PHP is prima geschikt als webtaal om bijvoorbeeld content te tonen, maar minder geschikt voor zware processen. Overigens is web performance zwaar overrated, je meot wel hele rare dingen doen wil je taal daar de bottle neck zijn, in vergelijking met de SQL overhead valt je script performance in het niet.

Ik wil PHP ook niet trollen, maar feit is dat ik het in sommige situaties verkeerd toegepast heb. (My bad)
Reccentelijk ben ik weer begonnen met een applicatie (wel specifiek voor het web) te maken, waar ik al performances issues had voordat ik iets functioneels had. Maar dit was niet aan PHP te wijten na ik wat onderzoek gedaan had Van belang is dat je je bottlenecks weet te vinden en inefficiente code eruit weet te halen.

[Confusion]

raptorix schreef op dinsdag 02 juni 2009 @ 13:15:
[...]
Nog een Jan Doedel die het over "snellere" code heeft, nogmaals geef me 1 voorbeeld van een webapplicatie waarbij de snelheid van je code echt van relevant belang was?

Voor iedere webapplicatie telt de gebruikerservaring. Als je van een responsetijd van 400 ms er 80 af kunt schaven door een opcode cacher, dan is dat het zeker waard.

[raptorix]

ACM schreef op dinsdag 02 juni 2009 @ 14:07:
[...]

Het hangt uiteraard van de toepassing, de schaalgrootte vs je servers etc af. Maar bij ons werd het grootst deel van de verwerking van de data voor de pricewatchcategorieen in PHP-code uitgevoerd. En dan is het echt wel van belang dat je zowel op indirecte (bijv via geheugengebruik/objectgroottes) als directe performance let. Ik heb daar iig de code al kwa performance teruggebracht van de eerste "werkende versie" die zo'n lijst met een paar duizend objecten in vele seconden, naar maximaal een seconde weten terug te brengen.

Het is uberhaupt al niet handig verwerking van data in code te doen, waarom denk je dat dat andere ding database heet?

[raptorix]

Confusion schreef op dinsdag 02 juni 2009 @ 15:13:
[...]

Voor iedere webapplicatie telt de gebruikerservaring. Als je van een responsetijd van 400 ms er 80 af kunt schaven door een opcode cacher, dan is dat het zeker waard.

Ga je code maar eens analyseren en dan zal je tot de conclusie komen dat responsetijd voor 90 tot 99% afhankelijk is van je database responses, kortom optimaliseer je queries/connecties en zie waar de echte winst ligt.

[raptorix]

_JGC_ schreef op dinsdag 02 juni 2009 @ 13:23:
[...]

Deze Jan Doedel kan tenminste lezen. Lees de hele reactie eens door voor je dit soort botte opmerkingen plaatst.

Excuses, ik wou niemand beledigen, maar ik zie dit soort threads nu al jaren voorbij komen, ik werk nu ruim 10 jaar als webdeveloper en voel me beetje roepende in de woestijn, nog steeds hoor ik mensen spreken over code in webapplicaties die niet performed, terwijl dat echt wel het laatste is wat je moet gaan proberen te optimaliseren.

[BtM909]

raptorix schreef op woensdag 03 juni 2009 @ 11:04:
[...]

Excuses, ik wou niemand beledigen, maar ik zie dit soort threads nu al jaren voorbij komen, ik werk nu ruim 10 jaar als webdeveloper en voel me beetje roepende in de woestijn, nog steeds hoor ik mensen spreken over code in webapplicaties die niet performed, terwijl dat echt wel het laatste is wat je moet gaan proberen te optimaliseren.

Wat moet je dan wel optimaliseren volgens jou?

[raptorix]

BtM909 schreef op woensdag 03 juni 2009 @ 11:16:
[...]

Wat moet je dan wel optimaliseren volgens jou?

Je database (queries) dan wel de manier waarop je je connections maakt.

[_JGC_]

Wat ik probeer te weerleggen is dat omgevingen als C++, Java of C# beter zouden zijn dan PHP met het oog op performance. Deze omgevingen hebben allemaal het grote voordeel dat code eenmaal gecompileerd wordt ipv bij elke request geparsed wordt. Bij PHP is dit gewoon een van de tijdvreters, wat je kunt oplossen met een opcode cacher of je spullen te precompilen met een produkt uit de Zend stal. Na die aanpassingen zijn er eigenlijk weinig tot geen verschillen meer in de snelheid van Java, C++, C# of PHP.
Verder ligt de bottleneck idd bij dingen als database en disk I/O, daar zullen de bottlenecks eerder liggen dan bij het stuk code dat je geschreven hebt, ervanuitgaande dat je geen gekke loops in je code hebt zitten.

Ik herinner me nog dat onze databaseserver ineens 30K queries/s uit de querycache stond te stampen. Voorheen was dit 3K queries/s. Bleek dat er een webpagina was die redelijk vaak aangeroepen werd, die in een loopje steeds dezelfde queries stond af te vuren op de databaseserver. Toen de webserver waar dit op draaide werd geupgrade van een single P4 3.0GHz naar een dual quadcore Xeon met 8x zoveel geheugen ging het aantal queries op de databaseserver nogal omhoog. In dit geval was het gewoon een bug in de code die onnodig databasequeries stond te versturen. Kwestie van de mysql_query buiten de foreach zetten en het was opgelost

[Confusion]

raptorix schreef op woensdag 03 juni 2009 @ 11:01:
[...]
Ga je code maar eens analyseren en dan zal je tot de conclusie komen dat responsetijd voor 90 tot 99% afhankelijk is van je database responses, kortom optimaliseer je queries/connecties en zie waar de echte winst ligt.

Been there, done that. Als je dan de responsetijd van 1 seconde naar 400 ms hebt gereduceerd, dan is het nog steeds de moeite een opcode cacher neer te zetten die er nog eens 80 ms afschaaft.

[ Voor 8% gewijzigd door Confusion op 03-06-2009 12:25 ]

[Patriot]

raptorix schreef op woensdag 03 juni 2009 @ 11:04:
[...]

Excuses, ik wou niemand beledigen, maar ik zie dit soort threads nu al jaren voorbij komen, ik werk nu ruim 10 jaar als webdeveloper en voel me beetje roepende in de woestijn, nog steeds hoor ik mensen spreken over code in webapplicaties die niet performed, terwijl dat echt wel het laatste is wat je moet gaan proberen te optimaliseren.

Waarom zijn die twee optimalisaties volgens jou eigenlijk exclusief aan elkaar? Je kunt toch én je queries e.d. optimaliseren, én je opcode cachen?

[Mr_Light]

raptorix schreef op woensdag 03 juni 2009 @ 11:25:
[...]

Je database (queries) dan wel de manier waarop je je connections maakt.

Pas als je observability tools dat zeggen. Het is niet verstandig dit maar allemaal gewoon aan te nemen.

Binnen de php programmeer cultuur is het lang zo geweest dat de database te pas en te onpas voor alles en nog wat word gebruikt.

Natuurlijk is het handig om je daar op te focussen waar de meeste tijd verbruikt word omdat daar de meeste winst te behalen is. Anderzijds is er de factor 'makkelijk-toe-te-passen' . Uiteindelijk is het optimaliseren ook terug te brengen naar hoeveel kost het en wat levert het op. effort ~ impact -> behaalde winst

Wat Confusion volgens mij probeert te zeggen is dat een opcode cacher mischien minder impact heeft als andere dingen maar daar tegenoverstaand dat het heel weinig effort kost.

En bij winst hoef je trouwens niet alleen aan gebruikers ervaring te denken, ook of je die extra server nodig hebt(of andere hardware), energie verbruik etc..

[ACM]

raptorix schreef op woensdag 03 juni 2009 @ 10:59:
Het is uberhaupt al niet handig verwerking van data in code te doen, waarom denk je dat dat andere ding database heet?

Soms zijn de bewerkingen zo complex dat je database het gewoon niet kan of je programmeerlaag het veel beter kan. Ik ken bijvoorbeeld geen database die "natural ordering" kan geven aan data. En de performance van queries neemt ook hard af als je een flinke hoeveelheid filters met joins moet toepassen (worst case al gauw 10x dezelfde tabel met andere filters opnieuw joinen). Daarnaast is een database niet zo goed in staat je in een keer te vertellen hoeveel records er in totaal waren voor een bepaalde set basisfilters, hoeveel er na het verwerken met uitgebreidere filters over waren gebleven en daar de Xe t/m Ye record van terug te geven. Dan moet je al gauw drie queries uitvoeren, als je die filtering uberhaupt al in een query wist te stoppen.

Overigens is een database voor het opslaan/ophalen en bewaren/bewaken van je data, eigenlijk helemaal niet voor het bewerken ervan. Lang niet alle vormen van bewerking van die data horen of kunnen in je database. Dat is vaak gewoon bussiness/display logic.

raptorix schreef op woensdag 03 juni 2009 @ 11:01:
Ga je code maar eens analyseren en dan zal je tot de conclusie komen dat responsetijd voor 90 tot 99% afhankelijk is van je database responses, kortom optimaliseer je queries/connecties en zie waar de echte winst ligt.

Dat hangt dus van je toepassing af, sowieso is 90-99% imho een zwaar overdreven getal. Tenzij je alleen maar wat triviale weergave van je data doet, kan je applicatiecode ook aardig wat tijd innemen. Bij PHP kost het al gauw relatief veel tijd om de files zelf te laden (wat de opcode cacher dus verhelpt), zeker als je codebase in de duizenden regels gaat lopen. Het verwerken van rijen defines is ook niet bepaald gratis. Complexe textuele bewerkingen, zoals wat geavanceerder correct html maken of het construeren van honderden "mooie urls", lopen ook flink op. Als je je data om wilt zetten naar json of xml kan je ook daar voor een relatief groot tijdsaandeel komen te staan. Template-parsers (zelfs de "naar php compilerende") kunnen ook aardig wat tijd kosten.

Als ik zo de prestatierapporten van tweakers.net zie, dan is de gemiddelde cputijd die wij opslaan (afgeleid uit getrusage) tussen de 15% en de 68%, met een gemiddelde over alle geserveerde requests van zo'n 55%. Uiteraard zit een deel van die tijd weer in het unserializen van data uit memcached en het verwerken van mysql-resultsets, maar het geeft toch een net wat ander beeld dan jij suggereerd. Als ik naar de totale geregistreerde tijd die niet besteed wordt aan queries (inclusief processing/unserialization) in mysql/memcached kijk varieert het van zo'n 22% tot 98% (gemiddeld 68%!). Daar zitten dan nog wel de eventuele connects naar mysql en memcached bij, maar zelfs als we daarvoor zouden corrigeren gok ik dat we op een gemiddelde tijd, die niet aan activemq, mysql en memcached besteed wordt, van in de buurt van de 30-40% zitten met uitlopers richting de 60%.

Daar kan je dus nog best wel interessante winsten boeken als je een optimalisatie in je php-code bedenkt.

Uiteraard is de beste optimalisatie doorgaans om niet iets efficienter te doen, maar er voor te zorgen dat je het helemaal niet hoeft te doen. Dus als het voor gebruik geschikt maken van de resultaten uit je database relatief kostbaar is, dan kan je ze vaak prima een paar minuten in memcached of een andere cachingomgeving opslaan. Als je dat soort dingen echter veelvuldig toegepast hebt (zoals wij dat hebben) kan je voor diverse pagina's er achter komen dat uiteindelijk een groot deel van de tijd overblijft binnen je applicatieomgeving.

[raptorix]

ACM schreef op donderdag 04 juni 2009 @ 08:28:
[...]

Soms zijn de bewerkingen zo complex dat je database het gewoon niet kan of je programmeerlaag het veel beter kan.

En dus ga je dat in PHP oplossen? Ik zou toch echt kiezen om hier een aparte service voor te schrijven.

Ik ken bijvoorbeeld geen database die "natural ordering" kan geven aan data. En de performance van queries neemt ook hard af als je een flinke hoeveelheid filters met joins moet toepassen (worst case al gauw 10x dezelfde tabel met andere filters opnieuw joinen).

Maak dan gebruik van een aparte database met gedenormaliseerde tabellen.

Daarnaast is een database niet zo goed in staat je in een keer te vertellen hoeveel records er in totaal waren voor een bepaalde set basisfilters, hoeveel er na het verwerken met uitgebreidere filters over waren gebleven en daar de Xe t/m Ye record van terug te geven. Dan moet je al gauw drie queries uitvoeren, als je die filtering uberhaupt al in een query wist te stoppen.

Is wel degelijk mogelijk, mits je een goed datamodel hebt.

Overigens is een database voor het opslaan/ophalen en bewaren/bewaken van je data, eigenlijk helemaal niet voor het bewerken ervan. Lang niet alle vormen van bewerking van die data horen of kunnen in je database. Dat is vaak gewoon bussiness/display logic.

Mee eens, hoewel databases hier steeds beter geschikt voor zijn, MS SQL heeft hier al erg goed features voor.

[...]

Dat hangt dus van je toepassing af, sowieso is 90-99% imho een zwaar overdreven getal. Tenzij je alleen maar wat triviale weergave van je data doet, kan je applicatiecode ook aardig wat tijd innemen.

Als je zorgt dat je data al grotendeels verwerkt beschikbaar is, dan is het inderdaad een questie van triviale weergave en dan zijn dat soort getallen normaal, ga je uitgebreide parsing doen in je code dan kan je natuurlijk optimaliseren tot je een ons weegt, maar in de helft van de tijd had je ook een proces kunnen schrijven wat je data al van te voren verwerkt.

Bij PHP kost het al gauw relatief veel tijd om de files zelf te laden (wat de opcode cacher dus verhelpt), zeker als je codebase in de duizenden regels gaat lopen. Het verwerken van rijen defines is ook niet bepaald gratis. Complexe textuele bewerkingen, zoals wat geavanceerder correct html maken of het construeren van honderden "mooie urls", lopen ook flink op. Als je je data om wilt zetten naar json of xml kan je ook daar voor een relatief groot tijdsaandeel komen te staan. Template-parsers (zelfs de "naar php compilerende") kunnen ook aardig wat tijd kosten.

Als ik zo de prestatierapporten van tweakers.net zie, dan is de gemiddelde cputijd die wij opslaan (afgeleid uit getrusage) tussen de 15% en de 68%, met een gemiddelde over alle geserveerde requests van zo'n 55%. Uiteraard zit een deel van die tijd weer in het unserializen van data uit memcached en het verwerken van mysql-resultsets, maar het geeft toch een net wat ander beeld dan jij suggereerd. Als ik naar de totale geregistreerde tijd die niet besteed wordt aan queries (inclusief processing/unserialization) in mysql/memcached kijk varieert het van zo'n 22% tot 98% (gemiddeld 68%!). Daar zitten dan nog wel de eventuele connects naar mysql en memcached bij, maar zelfs als we daarvoor zouden corrigeren gok ik dat we op een gemiddelde tijd, die niet aan activemq, mysql en memcached besteed wordt, van in de buurt van de 30-40% zitten met uitlopers richting de 60%.

Daar kan je dus nog best wel interessante winsten boeken als je een optimalisatie in je php-code bedenkt.

Uiteraard is de beste optimalisatie doorgaans om niet iets efficienter te doen, maar er voor te zorgen dat je het helemaal niet hoeft te doen. Dus als het voor gebruik geschikt maken van de resultaten uit je database relatief kostbaar is, dan kan je ze vaak prima een paar minuten in memcached of een andere cachingomgeving opslaan. Als je dat soort dingen echter veelvuldig toegepast hebt (zoals wij dat hebben) kan je voor diverse pagina's er achter komen dat uiteindelijk een groot deel van de tijd overblijft binnen je applicatieomgeving.

Waarom zou je dan uberhaupt PHP gebruiken als je performance zo dramatisch is?

[flashin]

Ik denk dat dat wel duidelijk is toch?

Een hele rewrite is nogal cruciaal.

[raptorix]

flashin schreef op donderdag 04 juni 2009 @ 12:58:
Ik denk dat dat wel duidelijk is toch?

Een hele rewrite is nogal cruciaal.

Blijven aanmodderen is gelukkig wel een oplossing.

[ACM]

raptorix schreef op donderdag 04 juni 2009 @ 12:54:
En dus ga je dat in PHP oplossen?

Dat werkte op zich prima, het was alleen een van de eerste keren dat ik echt heel serieus naar het geheugengebruik van een php-script moest kijken. En het was dan ook een voorbeeld waar de snelheid van de php-code wel degelijk relevant was. Daar vroeg je een voorbeeld voor en dat gaf ik je.

Ik zou toch echt kiezen om hier een aparte service voor te schrijven.

Toen duidelijk werd dat er nog meer functionaliteit aan toegevoegd moest worden en de datasets nog groter zouden gaan worden is dat dan ook gedaan.

Maak dan gebruik van een aparte database met gedenormaliseerde tabellen.

Voor de meeste van de deelproblemen was vast wel een sql-query-gebaseerde oplossing te verzinnen... Maar dan ben je uiteindelijk alleen nog maar omdat de data in de database zit de boel in de database aan het verwerken.

Is wel degelijk mogelijk, mits je een goed datamodel hebt.

SQL ondersteund in principe geen deelbewerkingen en tussenresultaten. Je kan vast wel de boel opsplitsen met temporary tables en dergelijke om dan de tussenresultaten te kunnen tellen, maar uiteindelijk is het dan al ineens een stuk minder eenvoudig dan jij doet voorkomen.

Mee eens, hoewel databases hier steeds beter geschikt voor zijn, MS SQL heeft hier al erg goed features voor.

Uiteraard, ik laat zelfs bij voorkeur de data in de database, dat is veel handiger.

Als je zorgt dat je data al grotendeels verwerkt beschikbaar is, dan is het inderdaad een questie van triviale weergave en dan zijn dat soort getallen normaal, ga je uitgebreide parsing doen in je code dan kan je natuurlijk optimaliseren tot je een ons weegt, maar in de helft van de tijd had je ook een proces kunnen schrijven wat je data al van te voren verwerkt.

En uiteindelijk verplaats je dan zoveel werk naar je voorwerk-procedures, dat die ook significante belasting op je systemen plaatsen. Het werk moet ergens gedaan worden en je kan niet altijd eenvoudig de boel voorbereid klaarzetten.

Waarom zou je dan uberhaupt PHP gebruiken als je performance zo dramatisch is?

Jij bent de gene die steeds roept dat de performance van PHP zo beroerd is, ik niet... Dus waarom zouden we wel overstappen? Het is een helse klus om de opgebouwde codebase te herbouwen in een andere omgeving, die niet alleen het herschrijven van code maar ook in veel gevallen nieuwe bibliotheken en paradigma en nieuwe methoden van testen en deployment vereist.
Bovendien zijn wij - in tegenstelling tot jou - wel van mening dat er op zijn minst "ruim voldoende" performance met PHP te behalen valt. Hoewel we wel reeel genoeg zijn om in te zien dat er ook punten zijn waar het beter op kan of kon.
Echter gaf ik die getallen niet aan om PHP af te branden, dat denk jij er uit op te mogen maken. Ik gaf enkel aan dat je ook in een stadium terecht kunt komen dat je het gros van je databasewerk zodanig geoptimaliseerd hebt dat er juist weer wel relatief veel tijd in je php-code gaat zitten...

[Voutloos]

raptorix schreef op donderdag 04 juni 2009 @ 12:54:
En dus ga je dat in PHP oplossen? Ik zou toch echt kiezen om hier een aparte service voor te schrijven.

Ja, want aparte services belasten je server gelukkig per definitie niet.

Maak dan gebruik van een aparte database met gedenormaliseerde tabellen.

Juist dit voorbeeld kan je niet alvast opslaan, ivm een groot aantal mogelijke filters.

Is wel degelijk mogelijk, mits je een goed datamodel hebt.

Onzin, je kan niet alle problemen fixen met een goed datamodel. En het hebben van een goed datamodel is eigenlijk een preconditie, dus die staat al.

Mee eens, hoewel databases hier steeds beter geschikt voor zijn, MS SQL heeft hier al erg goed features voor.

Je bent het er dus mee, met de kanttekening dat je MS SQl meer ruimte tot hacks hebt.

Als je zorgt dat je data al grotendeels verwerkt beschikbaar is, dan is het inderdaad een questie van triviale weergave en dan zijn dat soort getallen normaal, ga je uitgebreide parsing doen in je code dan kan je natuurlijk optimaliseren tot je een ons weegt, maar in de helft van de tijd had je ook een proces kunnen schrijven wat je data al van te voren verwerkt.

Je kan niet altijd alles van tevoren grotendeels weten[/]

Waarom zou je dan uberhaupt PHP gebruiken als je performance zo dramatisch is?

De is niet per se dramatisch. Een opcode zou eigenlijk wel standaard moeten zijn. Maar een aantal optimalisaties (doorgaans de grotere) zijn precies van dezelfde aard als bij andere talen: Het minimaliseren van werk bijv. minder inner loops en efficientere algoritmes. En daar kan je (en moet je), net als bij andere talen, gewoon een profiler voor gebruiken.

En met dat laatste kom je gewoon terug op het aloude cliche: meten=weten. Dat heb ik jou ook eens zien zeggen. Maar de volgende 2 'wetten' zijn toch duidelijk in tegenspraak: 'meten=weten' && '90-99% vd tijd zit _altijd_ in de database'. Als je die laatste uitspraak wijzigt in 'bij een weinig geoptimaliseerde applicatie is er grote kans dat de bottleneck bij de db ligt' kan ik er me er al stuk beter in vinden. Mar dan nog zal je het moeten meten.

[.oisyn]

raptorix schreef op donderdag 04 juni 2009 @ 13:15:
[...]

Blijven aanmodderen is gelukkig wel een oplossing.

Hier, een kleurenpallet


Kun je meer gebruiken dan alleen zwart en wit

[raptorix]

Ik ga vanwege tijdsgebrek niet alles quoten, wat betreft een aparte service: uiteraard kost dat ook CPU, maar webpagina's zijn niet handig (en ook niet bedoeld) om uitgebreide gegevensverwerking te doen, hier zijn aparte tools beter in, en ook nog eens beter te monitoren.

Nogmaals PHP is geen slechte taal, maar qua performance stukken minder als technologieen die precompiled zijn. Mijn standpunt is en blijft dat als je echt tegen performance problemen in websites aan loopt, je ernstig moet overwegen of datgene wat je doet wel in een website thuis hoort.

[Confusion]

raptorix schreef op donderdag 04 juni 2009 @ 17:26:
Ik ga vanwege tijdsgebrek niet alles quoten, wat betreft een aparte service: uiteraard kost dat ook CPU, maar webpagina's zijn niet handig (en ook niet bedoeld) om uitgebreide gegevensverwerking te doen

PHP != webpagina's. Het is gewoon een scripting taal, geschikt voor alles waar je ook perl, python of ruby voor in zou kunnen zetten.

Nogmaals PHP is geen slechte taal, maar qua performance stukken minder als technologieen die precompiled zijn.

Wat totaal irrelevant is als je niet het onderste uit de kan nodig hebt, zoals de meesten. Het verschil tussen goede PHP en goede C en veel kleiner dan het verschil tussen slechte PHP en goede PHP.

Mijn standpunt is en blijft dat als je echt tegen performance problemen in websites aan loopt, je ernstig moet overwegen of datgene wat je doet wel in een website thuis hoort.

Definieer 'website'. Er zijn zat applicaties wiens enige doel is om bepaalde content op het scherm te tonen. Als zo'n applicatie in Java geschreven is, dan is het goed en als hij in PHP geschreven is, dan niet?

(En even voor de goede orde: ik schrijf geen PHP en lees het liever ook niet)

[ Voor 8% gewijzigd door Confusion op 04-06-2009 18:00 ]

[Voutloos]

raptorix schreef op donderdag 04 juni 2009 @ 17:26:
... je ernstig moet overwegen of datgene wat je doet wel in een website thuis hoort.

Of iets echt nodig is is ook gewoon een standaard optimalisatie vraag.

Punt waarom iedereen lekker op elkaar reageert is dat de ondertoon van je posts ook een beetje te nadrukkelijk anti php/mysql lijkt.

[ Voor 32% gewijzigd door Voutloos op 04-06-2009 21:26 ]

[raptorix]

Voutloos schreef op donderdag 04 juni 2009 @ 17:53:
[...]

Of iets echt nodig is is ook gewoon een standaard optimalisatie vraag.

Punt waarom iedereen lekker op elkaar reageert is dat de ondertoon van je posts ook een beetje te nadrukkelijk anti php/mysql lijkt.

Ik ben geen fan van php, wat ik alleen zie is dat veel mensen die eenmaal beginnen met PHP nooit meer iets anders willen gebruiken, en de meest rare constructies gaan uithalen om iets te bereiken.

[raptorix]

Confusion schreef op donderdag 04 juni 2009 @ 17:51:
[...]

Definieer 'website'. Er zijn zat applicaties wiens enige doel is om bepaalde content op het scherm te tonen. Als zo'n applicatie in Java geschreven is, dan is het goed en als hij in PHP geschreven is, dan niet?
(En even voor de goede orde: ik schrijf geen PHP en lees het liever ook niet)

Anders lees je me posts even terug, mijn stelling is dat PHP geen slechte programmeertaal is, alleen dat heet iet overal even voor geschikt is.

[flashin]

En eigenlijk is iedereen het daar allang met elkaar overeens alleen je verwoord het een beetje grof?

[Peter]

raptorix schreef op vrijdag 05 juni 2009 @ 10:33:
[...]

Ik ben geen fan van php, wat ik alleen zie is dat veel mensen die eenmaal beginnen met PHP nooit meer iets anders willen gebruiken, en de meest rare constructies gaan uithalen om iets te bereiken.

Dat je geen fan bent is duidelijk, sterker nog, je loopt enkel negatief te zijn over PHP.

Als iemand PHP goed kan toepassen, met gebruik van goede logica en caching waar nodig, is het absoluut een prima taal. Zeker met gebruik van een aantal nieuwe PHP 5.3 functies- en verbeteringen heb ik meerdere applicaties gemaakt die een webpagina in minder dan een milliseconde kunnen afleveren. Dat een (groot)aantal mensen de taal niet goed toepast, workarounds-, hacks en andere smerige dingen in hun code gebruikt betekend niet dat goede code niet mogelijk is.

Voor heel veel doeleinden voldoet PHP prima; naast websites, CRM-pakketten, IRC bots zijn er zelfs DNS daemons in PHP geschreven die qua performance op 25% van BIND zitten, met wat simpele tweakers zelfs op 65-70 procent. Wie bepaald of PHP hier wel of niet voor bedoeld is? Ik zou het zelf niet gebruiken, maar als je de performance nog meer zou kunnen opkrikken en stevig test kan het een mooie basis vormen voor een gedistribueerd DNS systeem.

Ter info, ik programmeer zelf ook in C/C++, C# en/of andere talen wanneer de situatie daarom vraagt. De taalkeuze is vaak minder belangrijk dan de manier waarop je een applicatie implementeerd. Als je écht performance wilt moet je structureel alles in Assembly gaan schrijven.

Anyway, ontopic;

PHP tweaken voor optimalisatie kan een runtime-improvement van soms wel 30-40 procent betekenen. Zorg dat je PHP zelf compileerd ipv. binaries te gebruiken, zet extensies die je niet nodig hebt uit en gebruik inderdaad APC. In php.ini kan je vervolgens de optie "apc.stat" uitzetten voor productieomgevingen waardoor disk i/o niet meer voorkomt tenzei je applicatie daar gebruik van maakt. Gebruik caching, het liefst via APC of op een ramdisk en databases enkel wanneer echt nodig. Vaak kunnen resultaten gemakkelijk voor een aantal seconden, soms zelfs een minuut gecached worden, dat kan aanzienlijk schelen voor grotere websites.

[ Voor 16% gewijzigd door Peter op 05-06-2009 10:52 ]

[flashin]

En als dat optimaliseren niet genoeg werkt, dan hang je er net als hyves toch gewoon 1500 servers bij?

[raptorix]

Peter schreef op vrijdag 05 juni 2009 @ 10:49:
[...]


Dat je geen fan bent is duidelijk, sterker nog, je loopt enkel negatief te zijn over PHP.
]]]]]Een lang verhaal[[[[[[[[

Nogmaals ik ken ook mensen die hun Lada zo tunen dat ie 250 gaat, maar dat maakt het nog steeds geen sportwagen.

[Confusion]

raptorix schreef op vrijdag 05 juni 2009 @ 10:35:
[...]
Anders lees je me posts even terug, mijn stelling is dat PHP geen slechte programmeertaal is, alleen dat het niet overal even voor geschikt is.

Ik begrijp de relevantie van dit antwoord niet. Ik suggereer niet dat jij stelt dat PHP een slechte programmeertaal is. Ik herhaal dat jij stelt dat PHP eigenlijk alleen geschikt is voor "webpagina's" en dat het volstrekt onduidelijk is wat je daar precies onder verstaat. De uit JSP's opgebouwde admin waar ik op dit moment aan werk heeft als belangrijkste doel content te tonen. Niettemin moet er wat processing met die content gebeuren, waar ik liever een Java framework dan een PHP framework voor gebruik. Dat betekent niet dat iemand met meer verstand van PHP het niet prima in PHP zou kunnen nabouwen, zonder verlies in snelheid. Dat is mijn punt.

[Voutloos]

raptorix schreef op vrijdag 05 juni 2009 @ 11:17:
[...]
Nogmaals ik ken ook mensen die hun Lada zo tunen dat ie 250 gaat, maar dat maakt het nog steeds geen sportwagen.

Wat boeit het verschil nog als je met beide voldoende over de digitale snelweg (+1 voor de metafoor ) scheurt. Dat verschil boeit enkel indien:
1) Je compleet absurde kunstgrepen uitvoert voor dat tunen en dergelijk kunstgrepen zijn in dit topic nog niet langsgekomen.
2) Je per se een afkeer hebt van PHP.

[raptorix]

Ik ga hier niet meer op reageren, dit topic is compleet offtopic geraakt, ik denk dat alles wel gezegt is.

[flashin]

Nogmaals alles is de afgelopen pagina's wel 10x herhaald.

Iedereen is het eigenlijk allang met elkaar eens, maar jij verwoord het gewoon op een aparte haterige wijze.


Samenvattend:
PHP is niet de snelste taal, maar dat komt voornamelijk omdat alles wat je aanroept niet gecompileerd is. Dit kun je optimaliseren door bijv. opcode cachers, memcache, extra servers of door een extra service tussen je database en presentatie die het zware werk doet.
Wil je snelle applicaties ontwikkel dan in Assembly.

[_JGC_]

flashin schreef op vrijdag 05 juni 2009 @ 11:06:
En als dat optimaliseren niet genoeg werkt, dan hang je er net als hyves toch gewoon 1500 servers bij?

Je bedoelt dat als je code zo wazig is dat optimaliseren geen beginnen aan is?

Geen idee hoe de code van Hyves is overigens, maar als ik zie hoe de code en serverconfiguratie een dik jaar terug bij mijn huidige werkgever was... alleen al door het aanpassen van de serverconfiguratie zijn we van ondercapaciteit richting de 100% overcapaciteit gegaan. Hier en daar nog wat codetweaks zoals zo kort mogelijk je databaseconnectie openhouden deden de rest (als je een foto van 3MB via een PHP-script aan een chinees serveert, is het niet handig om de connectie pas na het versturen van de foto te sluiten ).

[raptorix]

_JGC_ schreef op vrijdag 05 juni 2009 @ 13:49:
[...]

Je bedoelt dat als je code zo wazig is dat optimaliseren geen beginnen aan is?

Geen idee hoe de code van Hyves is overigens, maar als ik zie hoe de code en serverconfiguratie een dik jaar terug bij mijn huidige werkgever was... alleen al door het aanpassen van de serverconfiguratie zijn we van ondercapaciteit richting de 100% overcapaciteit gegaan. Hier en daar nog wat codetweaks zoals zo kort mogelijk je databaseconnectie openhouden deden de rest (als je een foto van 3MB via een PHP-script aan een chinees serveert, is het niet handig om de connectie pas na het versturen van de foto te sluiten ).

Je ziet bij dit soort grote complexe sites wel vaker problemen, omdat de code ansich niet geschreven is op de capaciteit, daarnaast krijg je ook nog te maken met spagetti code omdat er geen mens meer is die precies weet wat er is, uit angst om bestaande zaken kapot te maken gaat men gelijksoortige functionaliteit klonen, wat in de toekomst voor nog meer chaos zorgt. Ik heb ooit een vrij groot project gedaan, waarbij na 3 jaar er 3 verschillende caching mechanismes waren gebouwd (nee de site was daarna nog steeds traag).

[Manuel]

raptorix schreef op maandag 08 juni 2009 @ 10:33:
[...]

Je ziet bij dit soort grote complexe sites wel vaker problemen, omdat de code ansich niet geschreven is op de capaciteit, daarnaast krijg je ook nog te maken met spagetti code omdat er geen mens meer is die precies weet wat er is, uit angst om bestaande zaken kapot te maken gaat men gelijksoortige functionaliteit klonen, wat in de toekomst voor nog meer chaos zorgt. Ik heb ooit een vrij groot project gedaan, waarbij na 3 jaar er 3 verschillende caching mechanismes waren gebouwd (nee de site was daarna nog steeds traag).

En dan wil jij de schuld aan PHP geven? Dat slaat toch nergens op, het ligt grotendeels aan de programmeur en hoe ze er tegenaankijken, dan pas kan je iets gaan vergelijken. In jouw "scenario" ligt het alleen aan de programmeurs als ik het zo lees, hun hebben de code gemaakt zoals die is, dan kan je niet de schuld aan het programma geven die alleen maar de inhoud "parsed".

Daarmee bedoel ik dat je eerst naar de programmeurs moet kijken en als laatste pas naar PHP zelf, kijk naar zijn/haar capaciteiten en ga dan pas conclusies trekken. Een overzichtelijke code brengt altijd meer goeds dan een niet overzichtelijke code

[raptorix]

Manueltje22 schreef op maandag 08 juni 2009 @ 10:53:
[...]


En dan wil jij de schuld aan PHP geven? Dat slaat toch nergens op, het ligt grotendeels aan de programmeur en hoe ze er tegenaankijken, dan pas kan je iets gaan vergelijken. In jouw "scenario" ligt het alleen aan de programmeurs als ik het zo lees, hun hebben de code gemaakt zoals die is, dan kan je niet de schuld aan het programma geven die alleen maar de inhoud "parsed".

Daarmee bedoel ik dat je eerst naar de programmeurs moet kijken en als laatste pas naar PHP zelf, kijk naar zijn/haar capaciteiten en ga dan pas conclusies trekken. Een overzichtelijke code brengt altijd meer goeds dan een niet overzichtelijke code

Waar geef ik de schuld aan PHP? Ik wordt continue van alles beschuldigt, door mensen die niet eens de moeite nemen om mijn reactie te lezen.

[Manuel]

raptorix schreef op maandag 08 juni 2009 @ 13:15:
[...]

Waar geef ik de schuld aan PHP? Ik wordt continue van alles beschuldigt, door mensen die niet eens de moeite nemen om mijn reactie te lezen.

Ik heb mijn reactie volgens mij gebaseerd op jouw voorgaande reacties..

[ Voor 0% gewijzigd door Manuel op 08-06-2009 13:25 . Reden: *typo ]

[raptorix]

Manueltje22 schreef op maandag 08 juni 2009 @ 13:24:
[...]


Ik heb mijn reactie volgens mij gebaseerd op jouw voorgaande reacties..

Dan moet je die quoten, en niet mijn reactie erboven.

[Manuel]

raptorix schreef op maandag 08 juni 2009 @ 13:29:
[...]

Dan moet je die quoten, en niet mijn reactie erboven.

Als ik alles moet gaan quoten waar ik reacties op wil geven dan staat een post van teveel tekens... Maar ik bedoelde dus voornamelijk (aangezien jij overal zegt dat PHP sloom is etc..) dat het aan de programmeurs lag en niet aan PHP zelf..

[raptorix]

Manueltje22 schreef op maandag 08 juni 2009 @ 13:32:
[...]


Als ik alles moet gaan quoten waar ik reacties op wil geven dan staat een post van teveel tekens... Maar ik bedoelde dus voornamelijk (aangezien jij overal zegt dat PHP sloom is etc..) dat het aan de programmeurs lag en niet aan PHP zelf..

En ik maak gewoon een opmerking over iets in het algemeen, en niet over PHP, dat jij daar gelijk andere conclusies aanverbind is voor jouw rekening. Maar ik stop hier nu echt over, veel succes met je PHP brouwsels.

[Voutloos]

En 'brouwsels' is nou precies een generaliserende, negatieve &*$@^^woordkeuze. En dergelijke woordkeuzes maak je in minstens de helft van je posts dus dan moet je niet verbaasd doen als men denkt dat je aan het bashen bent.

Maar dit topic moet hoe dan ook bij deze stoppen. Meten=weten, opcode cachers zijn dusdanig handig dat ze standaard aanwezig zouden moeten zijn, profilen voor het optimaliseren is het enige nuttige dat in dit topic staat.

[raptorix]

Voutloos schreef op maandag 08 juni 2009 @ 13:44:
En 'brouwsels' is nou precies een generaliserende, negatieve &*$@^^woordkeuze. En dergelijke woordkeuzes maak je in minstens de helft van je posts dus dan moet je niet verbaasd doen als men denkt dat je aan het bashen bent.

Maar dit topic moet hoe dan ook bij deze stoppen. Meten=weten, opcode cachers zijn dusdanig handig dat ze standaard aanwezig zouden moeten zijn, profilen voor het optimaliseren is het enige nuttige dat in dit topic staat.

Nou laten we er een wedstrijd van maken, zodat we eens goed kunnen kijken hoeveel het in snelheid scheelt, zijn we gelijk van het gelul af.

[mithras]

raptorix schreef op maandag 08 juni 2009 @ 14:13:
[...]

Nou laten we er een wedstrijd van maken, zodat we eens goed kunnen kijken hoeveel het in snelheid scheelt, zijn we gelijk van het gelul af.

Wat is het probleem nu precies? Als verschillende mensen een significante snelheidswinst behalen bij het instellen van een opcode cache, dan is dat toch een voordeel? In mijn applicatie kan ik 75% van de pagina's serveren zonder db access door de content te cachen. Met het installeren van bijvoorbeeld APC komt daar nog een snelheidswinst bovenop. Het optimaliseren van de database heeft weinig zin bij die 75%, het installeren van APC wel.

Ik werk al een tijdje met Zend Framework waar een aantal standaard caching mechanismen zijn ingebouwd om oa database queries te cachen. Die snelheidswinst is niet eens zo groot als ik ga kijken waar de echte bottleneck van de applicatie zit. De sql en script performance wat je noemt geldt dus ook echt niet in elk geval, bij iedereen

[_JGC_]

Ik gok dat die Zend cache lang zo optimaal niet is als wat ons straks met mysqlnd te wachten staat voor php 5.3.

Wat betreft PHP en brouwsels: als ik snel even een brouwseltje moet maken, doe ik dat in PHP ja. PHP leent zich heel goed voor brouwseltjes omdat het geen stricte taal is. Ik doe de laatste tijd ook wat programmeerwerk in C, wat qua ontwikkeltijd gewoon veel meer in beslag neemt dan PHP, maar als je het goed doet is de performance ook een stukje hoger. Ik zou C alleen echt niet gebruiken voor een website of een kort scriptje die even wat dingen in een database moet aanpassen.

Over snelheid van PHP tov andere talen: ik heb afgelopen week mogen zien hoe traag file_get_contents is. Ik heb een TCP socketserver in C geschreven die een opgevraagd bestand met sendfile() over de TCP socket gooit. Het uitlezen van een bestand met file_get_contents() is trager dan met stream_get_contents() hetzelfde bestand streamen over een TCP connectie via mijn servertje.

[Confusion]

raptorix schreef op maandag 08 juni 2009 @ 14:13:
[...]

Nou laten we er een wedstrijd van maken, zodat we eens goed kunnen kijken hoeveel het in snelheid scheelt, zijn we gelijk van het gelul af.

Als je er nou eens voor jezelf een wedstrijdje van maakt om aan te tonen dat je gelijk hebt, door dezelfde applicatie in PHP en je favoriete taal te maken? Doe maar een applicatie doen die op basis van een id en twee parameters een plaatje geschaald teruggeeft. GET /getImage?image_id=5&x=300&y=100 moet image 5 geschaald naar 300x100 opleveren.

[Creepy]

Voutloos schreef op maandag 08 juni 2009 @ 13:44:
Maar dit topic moet hoe dan ook bij deze stoppen. Meten=weten, opcode cachers zijn dusdanig handig dat ze standaard aanwezig zouden moeten zijn, profilen voor het optimaliseren is het enige nuttige dat in dit topic staat.

Precies.

Overigens gaat de onvriendelijkheid in dit topic twee kanten op. Dus iedereen die zich hierbij aangesproken voelt: let hier aub op. Het feit dat je het ergens niet mee eens bent kan wat subtieler worden gebracht.

Mocht er iemand echt nog wat nuttigs toe te voegen laat me het dan weten. Voorlopig gaat dit dicht want dezelfde zaken worden maar herhaald en herhaald.