Onderwerp: Welke hardware heb ik nodig voor website met forse database?

Hallo,

Als newbie op dit forum wil ik mezelf meteen introduceren als iemand met beperkte kennis van zaken.
Een vriend en ik hebben enige tijd terug een (Joomla) website gemaakt met een forse database daarachter. Omdat de site nog niet zo lang online is hebben wij gewoon gekozen voor een goedkope virtual hoster. Opzich is dat prima, want we hebben momenteel weinig bezoekers en gebruiken weinig ruimte, maar de snelheid laat echt te wensen over.
De database is voornamelijk opgebouwd uit 20.000+ dingen die op ruim 20 punten beoordeeld kunnen worden. Vooral wanneer er statistieken uit deze database getrokken moeten worden is de laadtijd ERG hoog, of heeft het een 500 server error tot gevolg. Een voorbeeld hiervan is bijvoorbeeld een top 10 best beoordeeld, slechts beoordeeld, meest beoordeeld, etc. Omdat voor een dubbetje op de eerste rij zitten niet gaat moet er dus gewisseld worden van provider.
Ik heb alleen geen idee waaraan een server moet voldoen om onze website op een goede manier te hosten. De site heeft naast die forse database ook wat nieuwsdingen, een community en forum. Niet zo spannend, maar vooral queries uitvoeren zijn een hel.

Mijn vraag is dus vooral; welke hardware is wel in staat om een dergelijke site goed te hosten. webreus.nl is dat in ieder geval niet (buiten de performance voor onze site een prima hoster).
Welke (dual) processor is nodig, geheugen, etc? Zou iemand een indicatie kunnen geven? Het liefst hoor ik dat virtual hosting (voorlopig) nog volstaat, ivm de kosten en geen opbrengst, maar ik ben benieuwd. Webreus heeft in ieder geval laten weten dat we teveel van de server gebruiken. (Om die reden hebben we de database ook beperkt tot 20k+ dingen ipv 130k, wat echt teveel was).

Alvast hartelijk dank voor de tips!

Hoe groot is je DB? Zorg dat je voldoende ram hebt. Als je DB echt groot is, of er veel in geschreven wordt, zorg dan dat je snelle disks hebt.

Ik denk echter dat je meer gaat willen door je queries te optimaliseren en te kijken naar indexen.

Inderdaad, aannemende dat het MySQL is kan de engine ook nog bepalend zijn voor de performance.
20000 artikelen klinkt niet echt als iets waar een beetje database server van over zijn nek gaat (met juiste indexen en queries).

20k is niks. Ik heb databases met meer dan een half miljoen rijen in sommige tabellen. Database is 400 mb o.i.d. En dat is zelfs nog weinig als ik deze vergelijk met een paar collega's.

Draait allemaal prima op een shared servertje.

Ik denk dat je geen indexes gebruikt of dat je queries een beetje raar zijn opgesteld...

Wat zijn je queries? Waar liggen je indexxen? Waarop filter je?

Want zoals andere zeggen, 20k moet geen probleem zijn.

Oorspronkelijk geplaatst door SF-Jeroen

20k is niks. Ik heb databases met meer dan een half miljoen rijen in sommige tabellen.

Hij had het over 20K artikelen, niet 20K rijen. Je kunt er wel van uit gaan dat elk artikel toch wel meerdere rijen met zich meebrengt. 20K artikelen kan zo 1 miljoen rijen zijn.

Maar, desondanks zou dat toch geen probleem moeten zijn, al zou ik zoiets toch niet op een shared hosting pakketje zetten. Ik zou eens kijken naar een VPS.

Qua performance van de server zou ik me niet al te veel zorgen maken. Iets waar je juist veel beter naar kan kijken, is hoe alles geoptimaliseerd is en dergelijke. Zo te horen kun je dit niet zelf, dus dan zou je dit of uit handen moeten geven, of een managed host zoeken die dit voor je kan regelen.

Voldoende RAM kan belangrijk zijn, maar ook zeker de disks. Een aantal partijen die ik ken hebben erg goede ervaringen met het gebruik van SSD's icm Mysql databases. Geeft een gigantische boost. Zorg er wel voor dat je SSD's met een goede levensduur neemt (SLC).

Processor is niet het belangrijkste mensen denken vaak van wel, neem behoorlijk wat Ram.
Je kan beter wat mindere processor nemen en meer Ram.

Ook een goede harddisk is belangrijk.

Ik durf er bijna gif op innemen dat hier geen probleem van hardware speelt, maar voornamelijk van de manier waarop de DB opgebouwd is, en welke queries uitgevoerd wordt, in combinatie met welke indexen.

@TS: als je het in keulen hoort donderen bij het woord "indexen", zoek dat iemand die uw site en scripting kan nakijken, samen met de database structuur. Ietwat kennis van zaken kan hier veel verschil maken.

Ik denk dat je het beste een server kan nemen met een hoge frequentie processor (dus bijvoorbeeld 3GHz ipv 4 x 2GHz) omdat hij dan sneller de query kan uitvoeren. Een SSD als opslag in bijvoorbeeld RAID10 (voornamelijk handig bij veel kleine queries) en veel geheugen is niet heel essentieel meer met SSD's maar is altijd nog een lekkere cache mogelijkheid. Geheugen kost tegenwoordig niet veel meer.

Een enkele SSD (Intel X25-M) haalt al ruim 250 MB/s t.o.v. SATA300 VelociRaptor ~125MB/s (op het snelste stuk). En een SSD heeft een seek time van om en nabij 0.1ms t.o.v. ~8ms van een VelociRaptor

Als je desktop hardware gebruikt zou ik een nieuwe Core i5 aanraden (turbo mode!) of een Intel E8600, zoveel mogelijk geheugen als je kunt betalen en een enkele Intel X25-M of voor de veiligheid naar RAID-1 gaan kijken.

Als server een kaal bestelde Dell R200 met leuke processor en 1 GB en PERC6i controller. En dan achteraf met 8 GB uitrusten, 2 x X25-M inzetten op RAID-1. Of een ASUS RS120 uit m'n hoofd (barebone) :-).

Sorry voor de late reactie. Ik ben vandaag de hele dag buiten het bereik van een computer geweest. Het betreft inderdaad een MySQL database met 22k artikelen met een 25 rijen per artikel waarop het beoordeeld kan worden. Elk artikel kan ook meerdere keren beoordeeld worden.
De rijen zijn nog lang niet allemaal gevuld (en zeker niet meerdere keren) en de database neemt ook maar iets meer dan 10MB in beslag. Momenteel heb ik voor de database 128MB ter beschikking gesteld. Ik kan dit wel verhogen, maar natuurlijk niet tot in het 'oneindige'. De site is tenslotte virtual gehost. Zou 128MB niet voldoende moeten zijn?

Indexen is idd een goede oplossing die wel een lichtje doet branden. Vroeger was ik vrij aardig op de hoogte van SQL, maar na 6 jaar SQL-loos te zijn ebt dat wel weg. Ik zal me toch eerst echt in moeten lezen voordat ik daar wat mee ga doen. Eerlijk gezegd ben ik momenteel nog teveel aan het worstelen met PHP en heb ik me over de SQL nog niet zo druk gemaakt. Veelal worden de normale instellingen van de toegepaste modules gebruikt.

De queries zijn overigens heel simpel. Gewoon simpele rangschikkingen, die wel alle rijen door moeten gaan. Ik moet overigens wel vermelden dat het op dit moment geen optie is om een eigen server te bouwen met SSD's, etc. Financieel zou dat wat onverantwoord zijn. De site brengt op dit moment (bewust overigens) nog geen cent op en kost dus enkel geld. De kosten binnen bepaalde perken houden is dus nog belangrijk. Dat er in de (nabije?) toekomst overgestapt moet worden op een eigen server had ik al wel voorzien, maar liefst pas als kosten en opbrengsten minstens in balans zijn.

Uit alle reacties (bedankt daarvoor overigens!) maak ik op dat vooral optimalisatie veel winst kan opleveren. Toch was onze huidige host was niet gelukkig met de grootte van de database en overstappen is dus wenselijk. Liefst weet ik dan van te voren waaraan deze host moet voldoen.
Ook vraag ik me dus af of 128MB voldoende is of ik dat het beste kan verhogen (ovigens wel met het risico dat de virtual server gaat swappen wat het helemaal erg maakt).

Juist de simpele queries kunnen vaak verbeterend worden naar 'geadvanceerde' queries.

Ik geloof niet dat je je hardware het probleem zijn, eerder je queries en de scripting.

Inderdaad je scripting heeft heel veel invloed en kan een eigen server nog onderuit trekken.
De grootte van de database moet geen enkel probleem zijn. Ik heb shared magento klanten op een server draaien met databases van meer dan een halve gieg zonder enkel probleem.

Oorspronkelijk geplaatst door Eddie

...
Ook vraag ik me dus af of 128MB voldoende is of ik dat het beste kan verhogen (ovigens wel met het risico dat de virtual server gaat swappen wat het helemaal erg maakt).

128 voor een ietwat site is wat laag, zeker als je hier een DB wil inladen, en daarnaast nog wat webserver-processen wil laten lopen. 256 zou ik als minimum nemen, met 512 moet je normaal wel al even wegkunnen.

Alles staat of valt met goede scripting en goede tuning van de componenten die je hebt (mysql buffers instellen zoals het hoort, op maat van de DB, kan een wereld van verschil betekenen inzake geheugengebruik en snelheid).