Vraag over bestandstoegang websites

[Verwijderd]

Hallo allemaal,

Ik heb de laatste tijd wat boeken gelezen over het maken van websites. Op dit moment ben ik een struktuur aan het bedenken voor mn website voordat ik echt aan het programmeren ga beginnen. Ik bedacht me opeens dat het wel eens lastig zou kunnen zijn om een (hopelijk) druk bezochte pagina te wijzigen als deze pagina steeds ook ingelezen wordt. Ik weet dat databases wel goed om kunnen gaan met concurerende toegang, maar de belasting voor de server zal ook aanzienlijk groter worden als je alle documenten in een eigen blob field zou gooien.

Ik ben bijvoorbeeld van plan om mn pagina de mogelijkheid te geven om nieuwstopics toe te voegen. Het idee is om het meest recente niewstopicnummer in een database op te slaan. Hierna zou index.php dit nummer uit de database inlezen en "vulhiernummerin.inc" includen. De 100e nieuwstopic staat opgeslagen in 100.inc. index.php zal ook een aantal oudere nieuwstopics includen 'nummer-min-1.inc' 'nummer-min-2.inc' etc. Deze bestanden worden redelijk vaak ingelezen, en de kans op lees/schrijf conflicten is dan ook aanwezig als het bestand aangepast wordt. Hetzelfde gebeurt denk ik als ik het bestand index.php wil aanpassen. De nieuwstopics zouden eventueel nog in een database gestopt kunnen worden, maar ik weet niet hoe ik het probleem met index.php op kan lossen. Als ik dit bestand wijzig dan zou dit steeds lastiger worden naarmate meer mensen het tegelijkertijd gebruiken toch?

Ik hoop dat jullie een tip voor me hebben.

mvg Bram

[Aloys]

Waarom maak je niet gewoon 1 pagina en stop je de data in de database. Zo'n database kan prima met een grote hoeveelheid gegevens omgaan.

[Verwijderd]

Sowieso moet je niet gaan optimaliseren als daar geen reden voor is. Het is een slecht idee om nieuwsberichten in bestanden op te slaan als je al een database tot je beschikking hebt. Zoals je al zegt gaan DBMS'en doorgaans al goed om met gelijktijdige verbindingen.

Als je niet steeds de naam van documenten wijzigt (dat is sowieso een slecht plan), heb je niet te maken met dit soort problemen. Sla de nieuwsberichten gewoon op in de database die je blijkbaar toch al tot je beschikking hebt. Mocht later blijken dat de server teveel tijd en moeite nodig heeft om pagina's te serveren, dan is het het waard om eens naar optimalisatie te gaan kijken in de vorm van caching.

[Verwijderd]

@ Aloys

Je bedoelt dat ik alle niewstopics in een database stop en dat ik dat inlees uit index.php?
Maar wat moet ik dan doen om index.php aan te passen waarin de opmaak van mn document verwerkt zit? Als ik dat een keer wil aanpassen dan zou dit een probleem om kunnen leveren. De opmaak kan eventueel ook wel in een database gestopt worden, maar er blijft altijd wat over in index.php . Of reduceer ik dit bestand tot een mysql query om de rest van index.php in te lezen uit een database?

[Haan]

Je gaat toch niet dagelijks aan je index.php zitten sleutelen als je site eenmaal live is? Als je dan een keer een wijziging wil doorvoeren doe je dat op een rustig moment, dat zo weinig mogelijk mensen er last van hebben.

Verder raad ik je aan om nog wat verder door te lezen over hoe je dit aan kan pakken

[ Voor 17% gewijzigd door Haan op 07-03-2009 12:11 ]

[Johnny]

Alhoewel ik mijn twijfels het voorgestelde systeem zou het geen probleem moeten zijn, je nieuwsbericht wordt slechts één keer geschreven, wellicht nog een keer aangepast en vele malen gelezen. Mocht je net toevallig het bestand aan het wegschrijven zijn terwijl iemand anders het opvraagt dan zou het bestandsysteem/database gewoon de oude versie nog moeten leveren, en zelfs als dat niet zo is dan heeft één bezoeker eenmalig een lege pagina.

Waar je wel op moet letten is dat meerdere mensen niet door elkaar hetzelfde bestand gaan wijzigen, dat is niet zo'n probleem voor je server maar wel voor die mensen omdat ze elkaar steeds overschrijven en dus alleen de laatste wijzigingen worden doorgevoerd.

[leuk_he]

Een gebruikelijke manier is je artikelen in de database op te slaan en de pagina dynamisch op te bouwen.

Je loopt dan inderdaad tenslotte tegen performance problemen op(dat duurt tegenwoordig langer dan je denkt, CPU cycles zijn goedkoop), En op dat moment ga je cache functies toevoegen.

Je kunt de database cachen
http://www.danga.com/memcached/

Of je pagina wat minder vaak opbouwene met php cache libraries

http://codeigniter.com/user_guide/general/caching.html
http://www.sitepoint.com/article/caching-php-performance/


Of je hangt er een proxy server voor die statische content cahced (die je dus wel hints geeft door expirey date in je http headers mee te geven.)

Wikipedia: Reverse proxy -> caching


===========
Het probleem wat jij probeert op te lossen, gelijktijdige toegang tot files, daar gebruik je locking voor, of je zet een semafoor waarbij je regeldat maar 1 proces mag schrijven als andere processen lezen en omgekeerd.

[ Voor 22% gewijzigd door leuk_he op 07-03-2009 12:15 ]

[Ramon]

Verwijderd schreef op zaterdag 07 maart 2009 @ 12:05:
@ Aloys

Je bedoelt dat ik alle niewstopics in een database stop en dat ik dat inlees uit index.php?
Maar wat moet ik dan doen om index.php aan te passen waarin de opmaak van mn document verwerkt zit? Als ik dat een keer wil aanpassen dan zou dit een probleem om kunnen leveren. De opmaak kan eventueel ook wel in een database gestopt worden, maar er blijft altijd wat over in index.php . Of reduceer ik dit bestand tot een mysql query om de rest van index.php in te lezen uit een database?

Hoeveel bezoekers verwacht je te hebben? Een simpele oplossing met een database is genoeg voor een hele hoop bezoekers. Tegen de tijd dat je site te traag wordt kan je gaan denken aan caching, of losse hardware. Ik denk dat je je druk maakt over dingen waar je je helemaal niet druk over hoeft te maken

[Thralas]

Snap ik het nu niet of bedoelt de TS gewoon:

Wat als de webserver een bestand probeert te serveren op het moment dat ik deze opsla?

Het exacte antwoord moet ik je helaas schuldig blijven, maar volgens mij levert dit in de praktijk geen problemen op.

[Creepy]

leuk_he schreef op zaterdag 07 maart 2009 @ 12:11:
Het probleem wat jij probeert op te lossen, gelijktijdige toegang tot files, daar gebruik je locking voor, of je zet een semafoor waarbij je regeldat maar 1 proces mag schrijven als andere processen lezen en omgekeerd.

Een beetje filesysteeem lost dit gewoon voor je op hoor. Daar hoef je niks voor te doen. De TS maakt zich zorgen om helemaal niks. Daarnaast snap ik niks van de door de TS aangedragen oplossing. nummer van de nieuwsitems opslaan in de db maar de content gewoon als platte files laten staan? Waarom? Wat tekst uitlezen uit een database stelt niks voor in fatsoenlijke database (aka, normaliseren dat ding ).. Pas als je daadwerkelijk tegen performance problemen aan gaat lopen ga dan controleren wat de bottleneck is los die op. Je bent nu een niet bestaand probleem aan het oplossen.

[ Voor 28% gewijzigd door Creepy op 07-03-2009 12:45 ]

[Verwijderd]

Thralas schreef op zaterdag 07 maart 2009 @ 12:21:
Snap ik het nu niet of bedoelt de TS gewoon:

Wat als de webserver een bestand probeert te serveren op het moment dat ik deze opsla?

Het exacte antwoord moet ik je helaas schuldig blijven, maar volgens mij levert dit in de praktijk geen problemen op.

Hier kwam mn vraag een beetje op neer ja Ik zag een scenario voor me waarin ik probeer iets te wijzigen, maar dat ik steeds foutmeldingen krijg omdat het bestand door iemand anders gelezen wordt. Maar als ik de reacties doorlees dan kom ik tot de conclusie dat ik me met dingen bezighoud waar ik waarschijnlijk nooit problemen van zal ondervinden. De nieuwsposts kunnen gewoon in een database gestopt worden dan en een eenmalige wijziging aan index.php zal waarschijnlijk een wit scherm voor hooguit een paar bezoekers opleveren.

Ik denk dat ik op een punt zit dat ik maar gewoon moet gaan beginnen met schrijven en de eventuele problemen aanpak wanneer ze voorkomen. Anders blijven dit soort niet theoretische problemen zich voordoen.

Bedankt voor de reacties allemaal. @ Leuk_he, ik zal je links nog een keer doorlezen. Bedankt voor je informatieve antwoord!

mvg Bram

[Verwijderd]

Creepy schreef op zaterdag 07 maart 2009 @ 12:42:
[...]

Een beetje filesysteeem lost dit gewoon voor je op hoor. Daar hoef je niks voor te doen. De TS maakt zich zorgen om helemaal niks. Daarnaast snap ik niks van de door de TS aangedragen oplossing. nummer van de nieuwsitems opslaan in de db maar de content gewoon als platte files laten staan? Waarom? Wat tekst uitlezen uit een database stelt niks voor in fatsoenlijke database (aka, normaliseren dat ding ).. Pas als je daadwerkelijk tegen performance problemen aan gaat lopen ga dan controleren wat de bottleneck is los die op. Je bent nu een niet bestaand probleem aan het oplossen.

Ik heb nog niet echt een gevoel voor proporties. Ik probeerde een concept te bedenken waarin de database zo min mogelijk gebruikt wordt. Het blijkt dus echter dat de databases zonder veel snelheidsverlies de hele nieuwsposts kunnen leveren.

[Aloys]

Verwijderd schreef op zaterdag 07 maart 2009 @ 12:05:
@ Aloys

Je bedoelt dat ik alle niewstopics in een database stop en dat ik dat inlees uit index.php?
Maar wat moet ik dan doen om index.php aan te passen waarin de opmaak van mn document verwerkt zit? Als ik dat een keer wil aanpassen dan zou dit een probleem om kunnen leveren. De opmaak kan eventueel ook wel in een database gestopt worden, maar er blijft altijd wat over in index.php . Of reduceer ik dit bestand tot een mysql query om de rest van index.php in te lezen uit een database?

Je zou een template van je index.php pagina kunnen maken en deze vervolgens vullen met informatie uit de database. Een ander idee is een header en footer maken. Dan roep je in je index.php-bestand eerst de header aan, daarna lees je de data uit de database en dan de footer uitlezen.

Sowieso kan je je nieuwsbericht in de database stoppen met opmaak (html) erdoorheen.

[mocean]

Ik denk dat alle grote nieuws-sites juist werken met alle nieuwsberichten in een database (met her en der wat caching). Als je een nieuwe site gaat maken, maak je dan niet druk over bezoekers. Als je een site maakt die binnen een jaar een paar-duizend pageviews per dag gaat trekken, dan kan de gemiddelde webserver dat prima af (met 2 vingers in de neus), en die aantallen ga je al niet snel halen.

En als je een business concept hebt dat wel duizenden bezoekers per dag zal gaan trekken, kan je beter een meer ervaren programmeur inhuren.

[André]

Move naar Programming

[roy-t]

Creepy schreef op zaterdag 07 maart 2009 @ 12:42:
[...]

Een beetje filesysteeem lost dit gewoon voor je op hoor. Daar hoef je niks voor te doen. De TS maakt zich zorgen om helemaal niks. Daarnaast snap ik niks van de door de TS aangedragen oplossing. nummer van de nieuwsitems opslaan in de db maar de content gewoon als platte files laten staan? Waarom? Wat tekst uitlezen uit een database stelt niks voor in fatsoenlijke database (aka, normaliseren dat ding ).. Pas als je daadwerkelijk tegen performance problemen aan gaat lopen ga dan controleren wat de bottleneck is los die op. Je bent nu een niet bestaand probleem aan het oplossen.

Nouja dit is niet alleen het bestandsysteem wat dit op moet lossen. Ik weet niet hoe appache hier mee om gaat maar ASP.Net werkt zo.

Je website draait in een apparte application pool, de aspx bestanden in je webroot map worden eigenlijk niet gebruikt, maar een schaduwkopie daarvan wel. Zodra je je bestanden aanpast (bijvoorbeeld door een nieuw login systeem te maken) kan het voorkomen dat pagina1Oud waar de gebruiker op zat naar pagina2Nieuw die je net hebt gemaakt ineens niet meer met elkaar kunnen samenwerken (omdat je terwijl de user pagina1Oud geladen had je deze en pagina2 vervangen had.

Daarom maakt IIS/.Net een nieuwe application pool aan op het moment dat je je website bestanden veranderd. De gebruikers die de oude pagina's geladen hadden blijven nog even in de oude applicationpool door gaan zodat zij netjes al hun request kunnen completen zonder errors door verschillende versies. Nieuwe gebruikers worden meteen naar de nieuwe application pool geleid.

Op deze manier hebben bezoekers er geen last van als je bestanden op je webserver veranderd. (Wel is het zo dat natuurlijk nieuwsberichten gewoon in een database horen ) Ik weet alleen niet hoe apache/php dit oplost (ik vermoed gewoon niet omdat apache niet zoiets als een application pool kent). Bij apache/php zou je dus dit probleem wel hebben, maar na een back en refresh door de gebruiker zou alles weer moeten werken en zou hij hoogstens een formulier opnieuw moeten invullen.

(IIS met php ondervangt dit probleem waarschijnlijk ook omdat IIS de application pools managed)

[Noork]

Verwijderd schreef op zaterdag 07 maart 2009 @ 12:49:
[...]


Ik heb nog niet echt een gevoel voor proporties. Ik probeerde een concept te bedenken waarin de database zo min mogelijk gebruikt wordt. Het blijkt dus echter dat de databases zonder veel snelheidsverlies de hele nieuwsposts kunnen leveren.

Waarom zou je niet gewoon beginnen met je site, en dan zie je wel hoe het loopt. Ik kan me niet voorstellen dat een beginnende website al een gemiddelde shared webserver kan dichttrekken. Gooi de content gewoon in een db, haal de content op met behulp van een id. Later kun je nog iets van disk caching toevoegen als dat nodig is (als file file_xxx.inc bestaat en datum < 30 minuten oud -> serve from filesystem o.i.d.). Als je Joomla/Wordpress o.i.d. gebruikt, kun je daar vast wel plugins voor vinden. Klaar is Bram.

[roy-t]

Noork schreef op maandag 09 maart 2009 @ 11:01:
[...]

Waarom zou je niet gewoon beginnen met je site, en dan zie je wel hoe het loopt. Ik kan me niet voorstellen dat een beginnende website al een gemiddelde shared webserver kan dichttrekken. Gooi de content gewoon in een db, haal de content op met behulp van een id. Later kun je nog iets van disk caching toevoegen als dat nodig is (als file file_xxx.inc bestaat en datum < 30 minuten oud -> serve from filesystem o.i.d.). Als je Joomla/Wordpress o.i.d. gebruikt, kun je daar vast wel plugins voor vinden. Klaar is Bram.

planning is tegenwoordig niet goed meer? Het is toch juist fijn dat de TS probeert om een website op te bouwen op zo'n goed mogelijke manier.

[Noork]

roy-t schreef op maandag 09 maart 2009 @ 13:17:
[...]
planning is tegenwoordig niet goed meer? Het is toch juist fijn dat de TS probeert om een website op te bouwen op zo'n goed mogelijke manier.

Dat schrijf ik niet, heel fijn hoor. Alleen ik vind niet dat de TS het zich onnodig moeilijk moet maken voor iets dat wellicht helemaal niet gaat lopen. Kijk b.v. naar Hyves, die zijn ook gewoon begonnen met de boel zonder zich op prestatie te richten. En kijk wat een succes het desondanks is geworden. Daarnaast is het misschien wel goed dat de TS zich eerst wat meer gaat verdiepen in de stof.

[roy-t]

Noork schreef op maandag 09 maart 2009 @ 13:30:
[...]

Dat schrijf ik niet, heel fijn hoor. Alleen ik vind niet dat de TS het zich onnodig moeilijk moet maken voor iets dat wellicht helemaal niet gaat lopen. Kijk b.v. naar Hyves, die zijn ook gewoon begonnen met de boel zonder zich op prestatie te richten. En kijk wat een succes het desondanks is geworden. Daarnaast is het misschien wel goed dat de TS zich eerst wat meer gaat verdiepen in de stof.

Ik ben het er zeker mee eens dat de TS zich eerst iets meer verdiept in de stof, maar om toch maar je hyves analogie aan te houden. Hyves was (is) een zooitje qua opzet, en had een ontzettend slechte reputatie qua snelheid toen het succes kwam hebben ze een compleet devteam neer gezet en een groot aantal servers om ervoor te zorgen dat alles een jaar later allemaal wel lekker werkt.

[MrBucket]

Verwijderd schreef op zaterdag 07 maart 2009 @ 12:49:
[...]


Ik heb nog niet echt een gevoel voor proporties. Ik probeerde een concept te bedenken waarin de database zo min mogelijk gebruikt wordt.

Je eerste reactie zou inderdaad kunnen zijn dat voorgegenereerde pagina's sneller geserveerd kunnen worden dan wanneer je ze on-the-fly door de webserver laat genereren. Maar, zoals je zelf al aangeeft:

Het blijkt dus echter dat de databases zonder veel snelheidsverlies de hele nieuwsposts kunnen leveren.

...dit is zonder meer waar (zeker als je bedenkt dat veel RDBMSen zelf een cache bijhouden van eerder uitgevoerde queries) Bovendien wil je echt niet in de situatie komen dat je al je webpagina-bestanden opnieuw moet genereren omdat je iets in de opmaak hebt aangepast.

Anders zou je voor de grap eens een stresstest moeten doen op een recht-toe-recht-aan php* website met achterliggende database, zonder je druk te maken over optimalisatie. Ik denk dat je verbaasd zult zijn over het aantal requests dat afgehandeld kan worden.

* Of ASP, of wat je dan ook van plan bent te gebruiken.

[Gomez12]

Verwijderd schreef op zaterdag 07 maart 2009 @ 12:49:
[...]
Ik heb nog niet echt een gevoel voor proporties. Ik probeerde een concept te bedenken waarin de database zo min mogelijk gebruikt wordt.

Serieus, dat is leuk als je webserver een 386 is. Alles sneller dan dat dan verlies je gewoon functionaliteit door je dbase niet te benutten waar hij voor gemaakt is.

Dit is gewoon premature optimisation, die volledig onnodig en extreem beperkend is.
Zelfs als je site al zo groot wordt dat je iets gaat merken van je tragere dan FS dbase dan nog ga je waarschijnlijk kiezen voor onderhoud in je dbase en caching op disk van de dbase elementen.

Het blijkt dus echter dat de databases zonder veel snelheidsverlies de hele nieuwsposts kunnen leveren.

Sterker nog, als je niet heel goed nadenkt over hoe je je FS indeelt is een dbase gewoon sneller omdat dat gewoon established technology is terwijl jij op je FS het wiel opnieuw probeert uit te vinden.

Alleen zie ik niet waarom het of blobs of files zijn? Een dbase kent vele tussenvormen als je niet enkel binarys gaat versturen. Gaat het enkel om binary files en niet om content dan verandert de opzet iets omdat dan gewoon 10Mb van disk ophalen sneller is dan 10Mb opvragen bij dbase server die het dan weer van disk (/ memory ) ophaalt en weer terugstuurt naar de webserver die het dan pas naar de client doorzet.

Maar dan nog biedt een dbase bepaalde voordelen ( ook al is het in dit geval trager ), zoals bijv simpeler backup traject ( 1 dbase tegenover x losse bestandjes ).

Maar bij gewone text-content is dit niet relevant, daar is een dbase over het algemeen gewoon sneller mee dan een FS omdat je bij een FS op een gegeven moment tegen een muur aanloopt ( als je niet je eigen dbase begint te maken ) met dynamic content ( aantal keer gelezen etc )