Site ombouwen naar eigen daemon

[BarthezZ]

Eerst even een korte inleiding: Als webdeveloper zijnde maak ik gebruik van een eigen gebouwd CMS, gebaseerd op PHP en een MySQL backend. Dit CMS heeft onder andere een volledig modulaire opzet waarbij het toevoegen van een functie niet meer is dan de feature lijst ophalen vanaf een centrale server, aanklikken wat je wilt, waarna de centrale server de taak van uploaden van language, template en code op zich neemt. Op zich werkt dit perfect, maar ik heb binnen mijn hoofd last van een aantal theoretische barrières en dingen die mogelijk beter kunnen. Daarbij ben ik dus bij het volgende idee gekomen, ondersteunt door potentieel veel vrije tijd, groei in gebruikers en dus deployments, ed.


Opzet
Mijn idee is om een volledige httpd op te zetten (en waarschijnlijk voor gedeeltes te forken vanaf projecten als lighttpd, etc.) waarbij de httpd op zich de code voor de websites in zich neemt. Ik denk namelijk dat er een hoop te winnen valt qua caching, acces times en protocol overhead.

Praktisch
Door het gebruik van 1 (threaded) httpd die ook alle code bevat voor de verschillende modules van de site wou ik de read times verminderen. Omdat het binnen 1 proces zou gaan draaien kan ik de templates en dergelijke direct in het geheugen laden en daar houden tot ze gewijzigd zouden gaan worden. Hierdoor heeft de server alles binnen een minimale tijd beschikbaar en hoeft dat niet voor elk request nog steeds in zich. Mijn (misschien foute) redenatie is namelijk dat voor elk request vaak de zelfde dingen steeds weer opnieuw opgehaald moeten worden.

Content caching
Door dingen als statistieken, sessie-data, statische pagina's, etc. in het geheugen te houden, maar ook als backup weg te schrijven naar danwel de MySQL server danwel de disk zelf, dacht ik ook hier een hoop winst op kunnen te behalen. Ook zou ik een tot enkele database connecties in stand kunnen houden waardoor er niet steeds een (naar mijn hoofd's theorie) connectie opgebouwd hoeft te worden.

Nu zijn eigenlijk de vraagstukken waar ik nog mee zit:
- Is dit uberhaupt een zinnige oplossingen
- Zijn de (enkele) aangedragen wel een probleem of is dat compleet verwaarloosbaar
- Is het verantwoord voor een middelmatige (in low level talen) coder om zoiets te maken en is de gedachte dat ik zoiets in the end efficiënter kan maken dan apache wel realistisch?

De rest van de praktische opzet wil ik nog verder uitwerken maar het leek me handig om misschien alvast wat input te krijgen.

[Confusion]

Heb je het hele traject van request naar response al geprofiled? Het lijkt me bijzonder onwaarschijnlijk dat de dispatching van de http daemon naar de php scripts de cruciale factor is.

[TheBorg]

- Is dit uberhaupt een zinnige oplossingen
Ik heb geen idee. Je caching verhaal klinkt logisch, maar in de real world zal bij een kleine site de meeste zooi toch wel uit e.o.a. (disk) cache komen. Tevens zal het socket gebeuren van bijv. apache ook een stuk sneller zijn dan de socket implementatie in PHP. Aan de andere kant heb je maar een paar regels extra nodig om de webserver volledig over te slaan.

- Zijn de (enkele) aangedragen wel een probleem of is dat compleet verwaarloosbaar
Ik voorzie geen problemen.

- Is het verantwoord voor een middelmatige (in low level talen) coder om zoiets te maken en is de gedachte dat ik zoiets in the end efficiënter kan maken dan apache wel realistisch?
Bouw het gewoon in PHP. Maak een socket server op poort 80 en run het in CLI modus. Zie hier voor een voorbeeld:
http://www.devshed.com/c/...rver-with-Sockets-in-PHP/
(heb het artikel niet in detail gelezen maar het geeft een goede indruk van wat er nodig is, er zijn nog meer voorbeelden te vinden)

Eén van de nadelen van OOP in PHP is dat je je mooi opgebouwde classes na elke request weer weggooit. Naar mijn mening is OOP in PHP alleen nuttig omdat het zo handig werkt, maar voor de performance is het niet best. Als je van je website een "statische" applicatie maakt dan is daar denk ik best winst te halen. Het is i.i.g. een mooi vraagstuk.

[YopY]

Ikzelf zou eerst eens kijken naar de alternatieven - het gebruik van Memcache met PHP om een aantal zaken in het geheugen te cachen tussen requests door en andersoorige optimalisaties. Je zou ook naar een persistente webapplicatie-omgeving kunnen kijken, zoals een website gebouwd met Java. Je hebt dan het voordeel van een persistente omgeving - elk request komt in dezelfde applicatie terecht, je kunt dus zaken langer in het geheugen vasthouden dan de request duurt - en het is eenvoudiger (imo) te ontwikkelen dan je eigen HTTP daemon. Ik heb overigens geen ervaring met die laatste.

Ik weet overigens ook niet of er nog meer alternatieven zijn, maar ik zou het zelf schrijven van een HTTP daemon als een laatste redmiddel zien, of bij een site waar de performance zeer belangrijk is en niet meer verbeterd kan worden door bijvoorbeeld het gebruik van Memcache en andere optimalisaties.

Kijk ook naar de kosten - is (bijvoorbeeld) het in gebruik nemen van een betere server die de eventuele performanceproblemen oplost goedkoper dan het opnieuw opbouwen van je software in een 'lagere' taal, zowel qua tijd, kosten en moeite.

[curry684]

TheBorg schreef op maandag 22 september 2008 @ 21:35:
Bouw het gewoon in PHP.

Goed plan - laten we de volledig uitgeoptimaliseerde C++ codebase van Apache vervangen door een hiervoor weinig geschikte interpreted scripttaal zodat we de marginale snelheidswinst die te halen is op genoemde punten die je ook elders beter zou kunnen oplossen direct weer met een factor 5 mag inleveren.

[LauPro]

De mod_python en mod_perl hebben de mogelijkheid om een applicatie als een soort service te draaien. Mijn ervaring hierbij is dat als er iets mis gaat de hele applicatie op zijn gat ligt. Bij PHP heb je je het dan over een enkel request dat het niet doet (mits het geen database-afhankelijke problemen zijn).

Dus vergis je niet in de impact die een probleem kan hebben op je site. Overigens is er een Nederlands bedrijf die een speciale HTTPd heeft geschreven in C++ met veel cachingopties waar (dacht ik) o.a. de site van uitzendinggemist.nl gebruik van maakt. Doordat alles in het geheugen wordt gerenderd haalt de site een zeer hoge performance.

Toch gaat hier behoorlijk wat tijd in zitten om een dergelijk systeem te maken.

[Creepy]

Zolang je het nog over theoretische problemen hebt en je doet dit project niet puur voor je eigen kennis dan zou ik het zeker niet gaan doen. De extra problemen die je tegen gaat komen omdat je iets aan het maken bent waar redelijk specifieke kennis van zaken voor nodig is wegen niet op tegen de theoritische zaken waar je bang bent om tegenaan te lopen.

Zorg voordat je aan zoiets begint dat je precies weet waar nu de bottlenecks van je eigen software liggen en ga die dan oplossen. Caching e.d. zijn ook op andere manieren dan een eigen geschreven http daemon op te lossen en de kans dat de protocol overhead je echte bottleneck is acht ik niet bestaand.

Wil je voor de lol een eigen http daemon schrijven om te kijken hoe dit werkt en er van te leren: gewoon doen. Verwacht echter niet dat je binnen no-time iets hebt dat sneller is dan de reeds bestaande software waar al echt jarenlang aan is gesleuteld.

[ Voor 16% gewijzigd door Creepy op 23-09-2008 13:45 ]

[TheBorg]

curry684 schreef op dinsdag 23 september 2008 @ 02:52:
Goed plan - laten we de volledig uitgeoptimaliseerde C++ codebase van Apache vervangen door een hiervoor weinig geschikte interpreted scripttaal zodat we de marginale snelheidswinst die te halen is op genoemde punten die je ook elders beter zou kunnen oplossen direct weer met een factor 5 mag inleveren.

Ik heb al aangegeven dat Apache bepaalde dingen veel sneller kan dan PHP, echter heb je zo wel in no-time een beeld van wat er allemaal nodig is om een systeem als dit te maken. Als TS direct in C++ gaat beginnen denk ik dat het traject zo lang wordt dat het halverwege ergens aan de kant geschoven wordt.

[Confusion]

TheBorg schreef op dinsdag 23 september 2008 @ 14:21:
Ik heb al aangegeven dat Apache bepaalde dingen veel sneller kan dan PHP

Het wordt allemaal niet duidelijker door dit soort appels en peren taalgebruik.

[frickY]

Heb je er wel aan gedacht dat je huidige Apache-omgeving ook al gewoon gebruik maakt van disk-caching, en dus nie tieder PHPtje telkens opnieuw van de schijf leest?

Ik denk dat het, als je deze weg in wilt slaan, je beter een extensie voor Apache kunt ontwikkelen met je codebase. Dan kun je vanuit compiled C werken in plaats van geinepreteerd PHP.

[ Voor 36% gewijzigd door frickY op 23-09-2008 14:42 ]

[Creepy]

frickY schreef op dinsdag 23 september 2008 @ 14:41:
Ik denk dat het, als je deze weg in wilt slaan, je beter een extensie voor Apache kunt ontwikkelen met je codebase. Dan kun je vanuit compiled C werken in plaats van geinepreteerd PHP.

En toen was de database je bottleneck

Echt: ga meten waar de vertraging zit en ga dat oplossen i.p.v. de hele boel direct om te gaan bouwen om een theoretisch probleem op te lossen.

[TheBorg]

Confusion schreef op dinsdag 23 september 2008 @ 14:25:
appels en peren

Ik begrijp je vraag niet.

[RobIII]

TheBorg schreef op dinsdag 23 september 2008 @ 17:33:
[...]

Ik begrijp je vraag niet.

TheBorg schreef op dinsdag 23 september 2008 @ 14:21:
Ik heb al aangegeven dat Apache bepaalde dingen veel sneller kan dan PHP

Apache is een Webserver, PHP is een scripttaal hence: appels en peren

Verder: eensch met Creepy. Meten is weten.

[ Voor 8% gewijzigd door RobIII op 23-09-2008 17:38 ]

[TheBorg]

Dan heb je mijn voorbeeld verkeerd geïnterpreteerd, het gaat er vanuit dat PHP alle taken van Apache overneemt.

[LauPro]

Een webserver in PHP? Dat gaat denk ik werkelijk een gigantische ramp worden qua memory usage.

PHP is niet gemaakt om standalone als een instantie te draaien, het is geoptimaliseerd voor korte uitvoertijden. De mentaliteit mbt geheugenallocatie is dan ook totaal anders dan bij Apache.

De vraag is hoeveel businesslogic je hebt in PHP. Als je die allemaal moet opbouwen kan je veel tijd kwijt zijn, misschien is een hybride oplossing iets. Dus voor je (zware) frontend een aparte daemon en de backend op een klassieke LAMP-configuratie.

[BarthezZ]

Creepy schreef op dinsdag 23 september 2008 @ 13:43:
[..]

Kennis en ervaring op doen zijn voor mij 2 hele belangrijke punten waarom ik hieraan wil gaan werken, maar puur kleine dingetjes doen valt niet echt binnen iets waar ik wat aan heb. Als ik aan zoiets wil gaan werken dan wil ik iets waar ik echt wat aan heb.

PHP als webserver is ook niet mijn uitgangspunt. Ik heb er al genoeg ervaring mee dat het hoogst waarschijnlijk niet de beste oplossing is voor een probleem als dit.

Creepy schreef op dinsdag 23 september 2008 @ 17:01:
[...]

En toen was de database je bottleneck

Echt: ga meten waar de vertraging zit en ga dat oplossen i.p.v. de hele boel direct om te gaan bouwen om een theoretisch probleem op te lossen.

Ik heb al een enorm deel aan optimalisaties doorgevoerd (maar eigenlijk weinig concreet gemeten) maar voordat ik daar nog verder in ga wil ik eerst zeker zijn in hoeverre het zin blijft houden en in hoeverre ik kan blijven optimaliseren met een "standaard" Apache&PHP&MySQL setup. Dan blijven er altijd een aantal dingen waarvan ik "vrij zeker" weet dat ik tegen limitaties aanloop, waaronder dus het bij elke request volledig opbouwen van de classes, database connectie, et cetera.
Zit ik er met die gedachte der mate naast dat het waarschijnlijk concreet niks uit zal maken, of is het een dermate groot project waar jullie huiverig van worden en me voor willen behoeden?

LauPro schreef op dinsdag 23 september 2008 @ 18:11:
De vraag is hoeveel businesslogic je hebt in PHP. Als je die allemaal moet opbouwen kan je veel tijd kwijt zijn, misschien is een hybride oplossing iets. Dus voor je (zware) frontend een aparte daemon en de backend op een klassieke LAMP-configuratie.

Hoe zou ik zo'n scheiding dan voor me moeten zien en wat bedoel je met hoeveel business logic ik in mijn PHP heb? Zou het dan bijvoorbeeld nuttig kunnen zijn om de data (en de transformaties daarop) af te handelen in een kleine AMP-backend en een no-nonsense template gedeelte te maken voor de communicatie en uiteindelijke vormgeving?

[LauPro]

BarthezZ schreef op dinsdag 23 september 2008 @ 18:42:
Hoe zou ik zo'n scheiding dan voor me moeten zien en wat bedoel je met hoeveel business logic ik in mijn PHP heb? Zou het dan bijvoorbeeld nuttig kunnen zijn om de data (en de transformaties daarop) af te handelen in een kleine AMP-backend en een no-nonsense template gedeelte te maken voor de communicatie en uiteindelijke vormgeving?

Allereerst moet je weten waar je performancewinst te halen valt. Over het algemeen in een frontend zwaarder dan een backend, al hoewel een backend natuurlijke krachtigere functies kan hebben.

Je zou er inderdaad aan kunnen denken om bijv. de content provider van je CMS in die daemon te stoppen en verder bijvoorbeeld business logic voor webshops/polls/fora etc in de back-end te houden (en met bijv. SOAP-achtig iets aansturen).

Uiteindelijk zul je niet alles in die daemon willen hebben en waarschijn qua architectuur ook neigen naar een modulair en scripted systeem.

[Confusion]

BarthezZ schreef op dinsdag 23 september 2008 @ 18:42:
[...]
Ik heb al een enorm deel aan optimalisaties doorgevoerd (maar eigenlijk weinig concreet gemeten)

Dan heb je dus waarschijnlijk al op een heel aantal plekken zinloos zitten optimaliseren.

maar voordat ik daar nog verder in ga wil ik eerst zeker zijn in hoeverre het zin blijft houden en in hoeverre ik kan blijven optimaliseren met een "standaard" Apache&PHP&MySQL setup.

Zoek maar eens uit welke enorm grote sites op een normale LAMP of LLMP stack draaien en hoeveel requests zij weten te serveren. Als jij denkt dat jouw requirements afwijken van die van hun, dan mag je wel met hele goede argumenten komen, in plaats van een gevoel. Als je alleen maar denkt dat je goede redenen hebt om van de regels af te wijken, dan heb je ze niet.

[ Voor 6% gewijzigd door Confusion op 23-09-2008 20:39 ]

[Creepy]

BarthezZ schreef op dinsdag 23 september 2008 @ 18:42:
[...]
Ik heb al een enorm deel aan optimalisaties doorgevoerd (maar eigenlijk weinig concreet gemeten)

Echt, ik herhaal mezelf voor de zekerheid nog maar eens een keer: ga aub meten waar je nu het gros van de tijd besteed. Als de code die je optimaliseert maar weinig wordt gebruikt in verhouding met overige code dan is de optimalisatie waarschijnlijk aardig nuttelos

maar voordat ik daar nog verder in ga wil ik eerst zeker zijn in hoeverre het zin blijft houden en in hoeverre ik kan blijven optimaliseren met een "standaard" Apache&PHP&MySQL setup. Dan blijven er altijd een aantal dingen waarvan ik "vrij zeker" weet dat ik tegen limitaties aanloop, waaronder dus het bij elke request volledig opbouwen van de classes, database connectie, et cetera.
Zit ik er met die gedachte der mate naast dat het waarschijnlijk concreet niks uit zal maken, of is het een dermate groot project waar jullie huiverig van worden en me voor willen behoeden?

Ik heb geen idee wa tje code is/doet etc. maar op gut feeling: Je bent je zeer waarschijnlijk op de verkeerde zaken aan het focussen. Again: meten!
Maar wat concreter: heb je nu een accuut probleem? Zijn er zaken traag? Zo nee, waarom dan nu al van te voren zonder dat je precies weet waar nu de bottleneck ligt iets willen gaan aanpassen?

Hoe zou ik zo'n scheiding dan voor me moeten zien en wat bedoel je met hoeveel business logic ik in mijn PHP heb? Zou het dan bijvoorbeeld nuttig kunnen zijn om de data (en de transformaties daarop) af te handelen in een kleine AMP-backend en een no-nonsense template gedeelte te maken voor de communicatie en uiteindelijke vormgeving?

Herhaling: meten!

Echt, als je wilt gaan optimaliseren zul je eerst moeten weten (door te meten ) waar het gros van de tijd in wordt besteed. Standaard regeltje: 80% van de tijd wordt door 20% van de code besteedt. Door die 20% code te achterhalen en te optimaliseren boek je dus de meeste winst.

Ondanks dat Apache een grote log iets lijkt is Apache echt niet traag. Er valt een hoop aan te tunen en in te stellen. Als je denktzeker weet (door te meten ) dat het aan apache ligt dan zou je eens naar lighttpd o.i.d. kunnen kijken maar zorg dan wel dat je een verschil qua performance kan meten. Maar of dat nu echt nuttig is, is echt afhankelijk van de rest vna de code. Dus alweer: ga meten waar het gros van de tijd wordt besteedt.

Oh, had ik al gezegd dat je eens moet gaan meten? Serieus: je zou echt niet de eerste zijn die totaal verkeerde code aan het optimaliseren is......

[ Voor 9% gewijzigd door Creepy op 23-09-2008 20:46 ]

[BarthezZ]

Ik ga maar eens meten denk ik
Alhoewel dat me waarschijnlijk nog altijd laat zitten met de gedachte een leuk project te beginnen

[curry684]

BarthezZ schreef op dinsdag 23 september 2008 @ 20:55:
Ik ga maar eens meten denk ik

Goed idee!

Alhoewel dat me waarschijnlijk nog altijd laat zitten met de gedachte een leuk project te beginnen

Serieus, ga die tijd lekker steken in je vriendin, een nuttig project, school, je carriere of weet ik het wat. Allemaal meer kans op goeie return-on-investment

[Comgenie]

Ah, duidelijk een herkenbare vraagstuk . Zelf heb ik inmiddels (in java) een http daemon gemaakt die statische content aan kan. Maar ook dynamisch .class files kan laden die de gehele sessie van gebruiker blijven geladen. (Ja, zoals hier boven al staat, nogal het wiel opnieuw uitvinden ).
Op zich voor de website projecten waar ik aan werk is het niet echt nodig, maar het leek me wel een leuk project. Iets waar ik wat van kan leren en trots op kan zijn . (Hij draait inmiddels al een aantal maanden foutloos op een dedicated server in amsterdam ).

Dus ja, alles is mogelijk maar je moet er wel veel tijd in willen steken.