Likes: 
Daniel Tryba wrote:
> Wat is het verschil tussen binarie en text? IMHO is er geen enkel
> verschil. Immers wat is tekst? Beperk je dat tot ascii, tot 8 bit dingen
> als iso-8859-x of zullen we meteen maar voor multibyte unicode gaan?
Hmm, ok. Klopt.
>>>Je kan plaatjes zonder problemen opslaan in een database,
>>
>><snip hoe dat gaat>
>>
>>Ik weet dat je plaatjes kunt opslaan in een database, maar ik zie het
>>voordeel er niet van in. Zie
>><http://www.yapf.net/faq.php?cmd=viewitem&itemid=621>. Of heb jij goede
>>tegenargumenten?
>
> Volgens mij stond er in het weggeknipte gedeelte dat als je het goed
> doet dat een bestand in een database geen extra nadelen heeft dan
> dynamische content vs. statische content. En dat wordt op bovenstaande
> URL ook verkondigt
> <q>
> Met andere woorden, je kunt data uit een database _alleen_ via een
> script ophalen, terwijl je een bestand op disk altijd rechtstreeks via
> bv een IMG tag kunt aanspreken. Dat scheelt nogal wat snelheid.
> </q>
>
> Veder begint het verhaal met 'Het klinkt heel erg handig, nooit meer
> fopen(), nooit meer fread() etc...'. Dit past totaal niet in de rest van
> het verhaal waar juist gestreden word tegen het processesn van content in
> een sss als je dat ook aan de webserver kan overlaten.
>
> Een leuk stukje:
> <q>
> Als je ze index pagina ophaalt worden er dus 9 scripts opgestart om de
> plaatjes op te halen (uitvoer van PHP scripts wordt in principe niet
> gecached, dus die scripts draaien altijd). Samen met het script dat de
> indexpagina zelf maakt heb je dan dus al 10 scripts nodig voor 1 pagina.
> Dus als je vijf pageviews tegelijk krijgt dan worden er 50 scripts
> gedraaid die alle 50 een query naar de database doen. Staan er 12
> plaatjes op je index dan worden dat er 5*16 = 80. Worden het 10 mensen
> dan zit je al op 160, twee keer de standaard waarde van mysql. En met
> zoveel gelijktijdige queries wordt mysql al snel traag.
> </q>
>
> Het begint al met dat de uitvoer van php paginas niet wordt gecached,
> zeker in het geval van statische plaatjes is dat natuurlijk heel dom en
> zonde van je processor tijd. Sla dus ook de last-modified tijd op en
> stuur die mee, browsers zullen dan vragen of het plaatje veranderd is en
> dat scheelt het overpompen van de data.
>
> Als je je webserver goed configureerd zullen meerdere requests over de
> zelfde connection gedaan worden (connection keep-alive). Het aantal
> connecties ligt dan in de zelfde orde grote als het aantal bezoekers.
>
> Een mysql database die ik in productie heb staan heeft z'n connection
> limit op 1000 staan, op de drukke momenten (zo'n 400 concurrent sessies)
> staan er zo'n 100 connecties daadwerkelijk open (persistant connecties).
> Op het drukste moment van vandaag (9:40) was de load '0.26 0.28 0.17'
> en was de machine 92% idle met 430 actieve sessies. Dat is toch iets
> meer dan het in het ramplenplan beschreven 30 gelijktijdige bezoekers.
> Nou moet ik wel toegeven dat ik daarvoor 2 frontend machines tot mijn
> beschikking heb (1 staat nog reserve), maar de load kan ook door 1
> frontend worden geserveerd, de 2de staat er tbv bereikbaarheid.
>
> Een testprogje wijst uit dat de het opentrekken van 1000 connecties
> resulteerde in het falen van de client (door z'n max processes heen), de
> server gebruikte op dat moment zo'n 500Mb, maar als je 1.5Gb over hebt
> als diskcache dan is dat absoluut geen ramp.
>
> De toegevoegde waarde van de centrale database, oa:
> -failover, er staat geen (user)data op de frontends het installeren
> van een frontend is niet meer dan het deployen van de code en in
> de loadbalancer mikken.
> -de database wordt gerepliceerd, als die machine afbrand staat er nog
> eentje naast met de zelfde data (wellicht dat je een paar seconden
> mist)
> -er is maar 1 datastore te archieveren.
>
> Toegevoegde waarde van data geserveerd door sss is oa de extra
> access-control laag die je kan toevoegen en veel meer data bij de data
> zelf kan opslaan dan het filesystem biedt.
<snip>
>>>>En je kunt het bestand bewerken zonder het eerst uit de database te
>>>>moeten halen.
>>>
>>>Maar hoevaak wordt er iets gewijzigt,
>>
>>Tsja, dat weet je nooit. Het zou echter wel kunnen gebeuren.
>
> Tuurlijk kan dat, maar zelfs indien het enkele keren per dag wijzigt,
> wat is dan het probleem? Bij de manuele handeling van wijzigen is het
> ophalen en opslaan maar 2 stappen extra.
>
>>>Je hebt wel gelijk, maar je vertelt nog steeds niet wat nu het
>>>bezwaar is tegen bestanden in een database. Heb je bv als eens met
>>>een gigantische directory zitten stoeien, een database is dan toch
>>>echt wat sneller.
>>
>>Nog nietMaar wat niet is kan nog komen, misschien zal ik ooit
>>inzien waarom het opslaan in een database beter is.
>
> Ik zeg niet dat het beter is, ik zeg dat het geen probleem is en dat het
> extra mogelijkheden met zich meebrengt. Ik kan niets anders zeggen dan:
> It works for me.
Bedankt voor je duidelijke verhaal. Ik zal het zeker nog een keer wat
uitgebreider bestuderen. In ieder geval is alles weer een stukje
duidelijker.
> Overigens is PHP niet de meest geschikte omgeving voor die soort
> spulletjes, connection pooling ontbreekt bv.
Check.
--
Cheers, Maarten Wierda
"Teenage angst has paid off well, now I'm bored and old"
Quote
