"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."
Voor vraag 2 : Volgens mij kan dit vrij hoog liggen met een caching systeem. Want 0.1 sec ( per include ??? ) lijkt mij erg hoog ervanuit gaande dat je include op filesysteem ( dus niet http:// etc. ) en dat je gewoon include en geen fopen / fread functies gebruikt.
Gewoon een goed caching systeem bouwen en de meeste problemen tijd zijn weg.
Wat denk je zelf dat er meer gebeurt ???
Meer lezen of meer toevoegen...
En maak je niet de fout om bij elke include een nieuwe sql-query op de dbase af te sturen ofzo??? Want de tijd lijkt mij echt te hoog liggen.
Zoals ik het lees doet hij dat al :Brakkie schreef op 11 september 2004 @ 16:30:
Ik zou ervoor zorgen dat bij elke aparte actie die beschikbaar is binnen je cms alleen de functionaliteit geinclude wordt die bij die actie nodig is. Dus bij een bericht toevoegen alleen de functies includen die je nodig hebt en niet alle functionaliteit.
Ik versta onder config tenminste ook rechten etc. Dus als tijdens eerste usercheck blijkt dat user geen mod-rechten heeft, dit dan ook niet meer naderhand includen en checken.Op dit moment include ik ongeveer 10 tot 15 bestanden (afhankelijk van de configuratie)
* Gomez12 gaat er vanuit dat als iemand nieuwe rechten krijgt hij best wel even opnieuw kan inloggen...
Ik neem aan dat je het nu over veel users client-side hebt. Die alleen maar read-operaties doen? Dan kan een caching systeem inderdaad enorm helpen.Reveller schreef op 11 september 2004 @ 16:05:
Zoals velen hier ben ik bezig met een CMS'je. Op dit moment include ik ongeveer 10 tot 15 bestanden (afhankelijk van de configuratie). Ik vind het prettig om mijn code op te delen in overzichtelijke, kleine bestanden.
Op dit moment heb ik een bestand van plm. 40 kb - 700 lijnen. Ik zit erover te denken om ook deze op te delen in logische aparte bestanden. Dit betekent echter wel dat ik per request 5 bestanden meer moet includen.
Met een eenvoudige test heb ik gemerkt dat het includen tot nu toe 0.1 seconden in beslag neemt. Ik vraag me af of dit niet exponentieel omhoog schiet wanneer er meer dan 1 gebruikers aan de site hangen. Vandaar mijn vragen:
• kan php een soort van gecompileerde versie van het cms onthouden zodat hij de bestanden niet op elke request opnieuw hoeft te includen?
• wat is een aanvaardbaar aantal includes per pagina?
Verwijderd
Bijv met een functie ( die ik dus include ) haal ik de nieuwste 5 posts uit mijn dbase. Als ik nu geen speciale fora heb, dan kan ik een keer de laatste 5 posts uit mijn dbase halen. Deze naar een txt-bestand schrijven.Verwijderd schreef op 11 september 2004 @ 16:52:
Wat verstaan jullie onder een 'cachesysteem voor includes'? De content van de files bijv. in het geheugen stoppen, of bedoelen jullie echt iets in PHP zelf?
En dan gewoon in mijn functie bovenaan iets zetten als : if file_exists "cache/laatste5posts.txt" then echo laatste5posts.txt else query(select....)
Nu hoef ik alleen maar als iemand en nieuwe post maakt het bestandje laatste5posts.txt te verwijderen en opnieuw aan te maken.
Dit heeft als voordeel dat ik ipv .txt er ook opmaakcodes etc in kan zetten.
Alleen hoe meer rechten / groepen / veranderende content hoe moeilijker het wordt om het op te zetten.
Vb De www.tweakers.net FP, deze kan elke 5 minuten opgebouwd worden en naar een static-file geschreven worden ( voor niet-ingelogde gebruikers!!! ) zodat niet elke gebruiker de dbase hoeft te benaderen maar alleen de static file. En dit is dan nog in blokjes te verdelen ook.
[ Voor 14% gewijzigd door Gomez12 op 11-09-2004 17:03 ]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 1-9-2003 17:16 (...) 3. - Inclusion of a 40kb file vs a 2kb file. 1-9-2003 17:51 - Results: 500 cycles: 40kb file: 26.94s, 1 cycle: 0.05389s 2kb file: 0.5s, 1 cycle: 0.001s So I would say the difference is rather shocking. 500 cycles, with unsetting all variables each cycle: 40kb file: 9.77s, 1 cycle: 0.01953s 2kb file: 0.49s, 1 cycle: 0.001s A little less shocking, but still quite amazing. |
[ Voor 3% gewijzigd door Cavorka op 11-09-2004 17:06 ]
the-blueprints.com - The largest free blueprint collection on the internet: 50000+ drawings.
Cavorka : Wat is dit voor een file die geinclude wordt??? En waar vinden de tijdsmetingen plaats ( server / client ) want ik vind dit heel schokkend als dit gewoon een txt-file is die geinclude wordt en naar de client gestuurd wordt. Als dit een php-file is die allerlei functies en query's bevat ( en geen goede case / if-else ) , dan vind ik het al iets logischer, graag enige onderbouwing.Cavorka schreef op 11 september 2004 @ 17:05:
Test van mij (lol ik heb hem echt al best vaak gepost, in allerlei topics ook) uit een log van een forum waar ik mee bezig was:code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1-9-2003 17:16 (...) 3. - Inclusion of a 40kb file vs a 2kb file. 1-9-2003 17:51 - Results: 500 cycles: 40kb file: 26.94s, 1 cycle: 0.05389s 2kb file: 0.5s, 1 cycle: 0.001s So I would say the difference is rather shocking. 500 cycles, with unsetting all variables each cycle: 40kb file: 9.77s, 1 cycle: 0.01953s 2kb file: 0.49s, 1 cycle: 0.001s A little less shocking, but still quite amazing.
Want dit is niet mijn ervaring en maandag kan ik het pas testen op mijn eigen comp.
Ik neem aan dat er gewoon PHP in de files staat, aangezien de tweede run elke keer de variabelen tussendoor unset. Maar wat er zo schokkend aan is?? Geen idee, dus het duurt .02 seconden om een 40Kb file te includen. Dat valt toc wel mee??Gomez12 schreef op 11 september 2004 @ 17:19:
[...]
Cavorka : Wat is dit voor een file die geinclude wordt??? En waar vinden de tijdsmetingen plaats ( server / client ) want ik vind dit heel schokkend als dit gewoon een txt-file is die geinclude wordt en naar de client gestuurd wordt. Als dit een php-file is die allerlei functies en query's bevat ( en geen goede case / if-else ) , dan vind ik het al iets logischer, graag enige onderbouwing.
Want dit is niet mijn ervaring en maandag kan ik het pas testen op mijn eigen comp.
Anyway, voor TS zou ik hier uit lezen dat het verstandig is om op te delen in kleinere includes. Aangezien de tijd om 20 maal een 2k file te includen gelijk is aan het includen van 1x 40kb. Als je gemiddeld de helft van die includes gebruikt bespaar je dus gemiddeld 0.01 seconde \0/.
Regeren is vooruitschuiven
Verwijderd
Oké, dat is het cachen van queries, templates, .... maar wat heeft dat te maken met includes? Wat jij hier allemaal vertelt is gewoon een manier om het hele gebeuren te versnellen, maar imho heeft het echt niets te maken met de tijd om bestanden te includen en dat eventueel te versnellen.Gomez12 schreef op 11 september 2004 @ 17:00:
[...]
Bijv met een functie ( die ik dus include ) haal ik de nieuwste 5 posts uit mijn dbase. Als ik nu geen speciale fora heb, dan kan ik een keer de laatste 5 posts uit mijn dbase halen. Deze naar een txt-bestand schrijven.
En dan gewoon in mijn functie bovenaan iets zetten als : if file_exists "cache/laatste5posts.txt" then echo laatste5posts.txt else query(select....)
Nu hoef ik alleen maar als iemand en nieuwe post maakt het bestandje laatste5posts.txt te verwijderen en opnieuw aan te maken.
Dit heeft als voordeel dat ik ipv .txt er ook opmaakcodes etc in kan zetten.
Alleen hoe meer rechten / groepen / veranderende content hoe moeilijker het wordt om het op te zetten.
Vb De www.tweakers.net FP, deze kan elke 5 minuten opgebouwd worden en naar een static-file geschreven worden ( voor niet-ingelogde gebruikers!!! ) zodat niet elke gebruiker de dbase hoeft te benaderen maar alleen de static file. En dit is dan nog in blokjes te verdelen ook.
Misschien moet je wat minder includes doen, omdat het resultaat van die includes in je cache zit, maar dat heeft niets met include'n op zich te maken.
[ Voor 7% gewijzigd door Verwijderd op 11-09-2004 17:48 ]
Waarom include jij een file???Verwijderd schreef op 11 september 2004 @ 17:44:
[...]
Oké, dat is het cachen van queries, templates, .... maar wat heeft dat te maken met includes? Wat jij hier allemaal vertelt is gewoon een manier om het hele gebeuren te versnellen, maar imho heeft het echt niets te maken met de tijd om bestanden te includen en dat eventueel te versnellen.
Ik gebruik het omdat ik die functie / file later nog wel eens wil hergebruiken.
Hergebruiken is in 90% van de gevallen gewoon te cachen, dus als je het hergebruiken kan versnellen kan je ook het includen cachen.
TS> Volgens mij is de overhead niet zo heel groot. Zeker niet als je servertje een mooie HD met 8MB cache heeft.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Gomez12 schreef op 11 september 2004 @ 17:19:
[...]
Cavorka : Wat is dit voor een file die geinclude wordt??? En waar vinden de tijdsmetingen plaats ( server / client ) want ik vind dit heel schokkend als dit gewoon een txt-file is die geinclude wordt en naar de client gestuurd wordt. Als dit een php-file is die allerlei functies en query's bevat ( en geen goede case / if-else ) , dan vind ik het al iets logischer, graag enige onderbouwing.
Indeed, gewoon PHP, het waren data files (die ik dus als PHP formaat naar txt bestanden schreef), elke topic kreeg dus een eigen data-file, als:T-MOB schreef op 11 september 2004 @ 17:29:
[...]
Ik neem aan dat er gewoon PHP in de files staat, aangezien de tweede run elke keer de variabelen tussendoor unset.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| <?php $threadtitle = "1" ; $post_option = "normal" ; $name[] = "Admin" ; $userid[] = 1 ; $message[] = "2 <br>[center][1]Editted: 23 Sep 2003 - 16:23:46[1][/center]" ; $mess_timestamp[] = 1063296830 ; $ip[] = "127.0.0.1" ; (...etc etc...) $name[] = "Admin" ; $userid[] = 1 ; $message[] = "More and more." ; $mess_timestamp[] = 1063551571 ; $ip[] = "127.0.0.1" ; ?> |
[ Voor 21% gewijzigd door Cavorka op 11-09-2004 18:45 ]
the-blueprints.com - The largest free blueprint collection on the internet: 50000+ drawings.
Om problemen te voorkomen kun je misschien beter het cachen zo doen dat je niet de gegevens, maar de ARRAY met de gegevens erin opslaat in een file. Dit kan dmv Serialize en unserialize. Je kunt de gegevens dan bij het teruglezen alsnog parsen en eventueel een selectie maken (op usertype oid)
Artikeltje erover:
http://www.zend.com/zend/tut/tutorial-staub2.php
// NB: Bij dit artikel moet je (mijns inziens) niet letten op de manier waarop de artikelschrijver denkt over het laten "verlopen" van de cache. Ik zou dat ook gewoon met een functietje doen.