wat is sneller bestand vs database

Zoals reeds eerder genoemd is het voor 3.500 profielen niet de moeite waard om ook maar iets aan caching te doen.

Daarnaast denk ik dat je niet alleen naar de opslag moet kijken, maar naar het hele proces.
Indien je via php de cache bestanden gaat includen heb je nog steeds een relatief grote overhead door het gebruik van PHP zelf.

Voor sites met een hoog bezoekersaantal kan je daarom beter de uitvoer van PHP cachen.
Proxy servers zoals squid zijn hiervoor in te stellen.


Indien je toch PHP wilt gebruiken, vergeet dan niet de laatste wijzingsdatum mee te sturen.

PHP Code:

---

$last_modified = date('D, d M Y H:i:s', $TIMESTAMP_VAN_BESTAND_OF_UIT_DATABASE).' GMT';

if ( isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ) 
{
    if ($_SERVER['HTTP_IF_MODIFIED_SINCE'] == $last_modified) 
    {
        header("HTTP/1.1 304 Not Modified");
        exit(0);
   }
}

 header("Last-Modified: ".$last_modified); 


---

Dit wordt vaak vergeten en dan werkt de browser cache aan de kant van de bezoeker totaal NIET.

Ik blijf erbij dat het opslaan en dan recachen van een file gewoon prima moet werken in dit soort gevallen. Ik doe het ook voor heel veel sites. Gewoon zorgen dat er een functie is die checked of de cache file bestaat en hem dan included.

Mocht je toch perse files willen... good luck... :) Mag je een flinke class voor gaan schrijven om dat allemaal managable te houden (vooral ook searchable)

BTW: Een profiel van 50KB? Hoeveel regels is dat dan :S:S dat moet wel een flink profiel zijn dan.

Citaat:

---

Origineel geplaatst door WE-Create!
Ik blijf erbij dat het opslaan en dan recachen van een file gewoon prima moet werken in dit soort gevallen. Ik doe het ook voor heel veel sites. Gewoon zorgen dat er een functie is die checked of de cache file bestaat en hem dan included.

Mocht je toch perse files willen... good luck... :) Mag je een flinke class voor gaan schrijven om dat allemaal managable te houden (vooral ook searchable)

BTW: Een profiel van 50KB? Hoeveel regels is dat dan :S:S dat moet wel een flink profiel zijn dan.

---

Profielkinderen zijn geen html programmeurs We-Create :)

Citaat:

---

Origineel geplaatst door Xerious
Database is volgens mij toch sneller hoor,

UBB Classic slaat ook data op in bestanden, met als gevolg dat een beetje grote site al snel een dedicated server nodig heeft om een acceptabele belasting te houden.

---

Je haalt een aantal zaken door elkaar.

UBB Classic was 100% op bestanden gebouwd. In UBB classic zoeken, alsmede 'database'(bestand)bewerkingen op een groot UBB forum, ging traag.

De topicstarter wil weten of het zinvol is om veelopgevraagde data te cachen. Het antwoord is natuurlijk: ja! Zoekpagina's en dergelijke kunnen wel degelijk nog gebruik maken van de (een) (MySQL) database, maar statische HTML-pagina's die slechts 1x per week of iets door gebruikers worden geupdate hoeven natuurlijk niet allemaal in de database te staan.

De cache-file van een bepaalde gebruiker werk je alleen bij op het moment dat hij/zij een wijziging aanbrengt op zijn/haar profiel, of als er bijv. een reactiebericht bijgekomen is.

Zorg er wel altijd voor dat je data óók in de database hebt staan! Als je straks 100.000+ gebruikers hebt (100.000+ files in één directory) dan wordt het weer minder prettig voor je server. Het kan dan handiger zijn om alles te (laten) benaderen vanaf bijv. een PostgreSQL server!

Succes!

D.M.

Volgens mij gebruiken vrijwel alle moderne besturingssystemen een "hash"-functie in directorystructuren. Hierdoor is het opzoeken van een file op naam ook nog zeer snel wanneer er veel files in een directory staan, en vergelijkbaar met een index scan op een database tabel. Een database kan hier niet veel op verbeteren. Heb je veel files en wordt het onhandelbaar, dan kun je zelf een "hash" maken door de bestanden in subdirs 0/ 1/ 2/ etcetera te verdelen.

Als de data niet al te veel wijzigt, zou ik altijd voor de optie van cachebestanden kiezen!

Wat betreft snelheid maar vooral ook efficientie zou ik een database (server) gebruiken. Deze zijn er simpelweg voor gemaakt om zo efficient dus snel mogelijk informatie op te halen, en cachen van de profielen is enkel logisch indien het opbouwen van de definitieve pagina relatief zwaar zou zijn, maar dan zou ik dus ook kiezen voor de optie waarbij de profielen zelf in de database staan en de profielen 24 uur lang in een directory /cache onder id of hash gecached worden om ze rechtstreeks te includen bij de eerste opvraging.

HAHA, heel mooi allemaal.

Julle spreken elkaar allemaal tegen, vanuit persoonlijke ervaringen waarschijnlijk...

Ik heb in ieder geval weer wat meer info.

Ik ga even kijken wat ik de klant ga aanbevelen.

Bedankt.

Ik zou zeggen kijkw at de huidige situatie is en hoe het draait en doe een klein performance testje door een deel te gaan doen op de andere manier en ga dat eens vergelijken.

Ik vind hte zelf bijvoorbeeld HEEL belangrijk dat ik ten alle tijden alle profielen kan bekijken en doorzoeken op onlegitiem (lees pornografisch/rasistisch) materiaal, met files gaat dat niet, maar met een DB daarintegen wel weer. vandaar dat ik groot voorstander ben van db icm cachefiles.

Het is gewoon afwegen wat je eisen en wensen zijn.

Wat wij doen voor een aantal sites is het volgende:

Alle gegevens staan in een database en worden daarin aangepast.

Na het aanbrengen van een wijziging in de database omtrent een speciale user bijvoorbeeld worden de statisch gegenereerde gegevens van die gebruiker weggegooid, maar nog niet opnieuw aangemaakt.

Pas op het moment dat de gegevens van deze gebruiker worden opgevraagd wordt gekeken of al een statische pagina bestaat en anders wordt deze gegenereerd. Daarmee voorkom je dus ook het genereren van statische bestanden die wellicht helemaal niet nodig zijn omdat deze tussen de aanpassingen helemaal niet worden bekeken.

Daarnaast krijg je vaak bij grote directories dat deze traag worden door het moeten opzoeken/uitpikken van het juiste bestandje. Dit pakken we aan door een directory structuur die wat dieper gaat, maar wel maar max 100 bestanden in de directory heeft staan.
profiel 22.532 zou dan in als volgt opgepikt worden:
pad/naar/de/bestanden/2/25/32.html

Citaat:

---

Origineel geplaatst door Pinocchi
Wat wij doen voor een aantal sites is het volgende:

Alle gegevens staan in een database en worden daarin aangepast.

Na het aanbrengen van een wijziging in de database omtrent een speciale user bijvoorbeeld worden de statisch gegenereerde gegevens van die gebruiker weggegooid, maar nog niet opnieuw aangemaakt.

Pas op het moment dat de gegevens van deze gebruiker worden opgevraagd wordt gekeken of al een statische pagina bestaat en anders wordt deze gegenereerd. Daarmee voorkom je dus ook het genereren van statische bestanden die wellicht helemaal niet nodig zijn omdat deze tussen de aanpassingen helemaal niet worden bekeken.

Daarnaast krijg je vaak bij grote directories dat deze traag worden door het moeten opzoeken/uitpikken van het juiste bestandje. Dit pakken we aan door een directory structuur die wat dieper gaat, maar wel maar max 100 bestanden in de directory heeft staan.
profiel 22.532 zou dan in als volgt opgepikt worden:
pad/naar/de/bestanden/2/25/32.html

---

Tja, dit is volgens mij gewoon de meest ideale manier, alleen dan moet je er ook voor zorgen dat een nieuw gegenereerde dir ook gelijk een .htaccess mee krijgt.

Die dir zetten we buiten het zichtbare bereik van bezoekers, dus dat levert verder geen problemen op als dat tenminste is wat je bedoeld

Bij grote tekstvelden (denk aan > 3 KB, dat neem ik altijd als limiet) kun je inderdaad beter een veld naar bestand wegschrijven.