Database te groot: site opsplitsen?

Hallo,

Ik overweeg momenteel een Joomla-site die ik in aanbouw heb, op te splitsen over meerdere installaties. Echter, dit brengt de nodige complicaties met zich mee...

Situatie nu:
- Joomla CMS (draait / is gebouwd rondom 1 fotogalerij-extensie)
- Gehost op een VPS (4e server waar we het op proberen)
- Grootte is rond de 50GB (loopt over de komende 2 jaar op naar 150GB)
- Database is rond de 10MB
- Site (frontend/backend) is 3 tot 5x zo traag met laden als een gemiddelde site
- Cache (conservatief) staat aan
- Gzip Compressie staat aan

De site is een foto-archief, onderverdeeld in meerdere (sub)categorieën per jaar. Nu zat ik er aan te denken om:
1) de jaartallen los te koppelen
2) nieuwe subdomeinen aan te maken (2012.domein.com, 2011.domein.com etc.)
3) installatie van Joomla CMS, template & extensie
4) de foto's + bijbehorende (sub)categorieën per jaar te uploaden onder de juiste subdomein

Het voordeel wat ik hiervan in zie, is dat er weliswaar meerdere databases worden aangemaakt, maar dat iedere database daarmee dusdanig wordt verkleind, dat de site(s) weer sneller zouden moeten functioneren. Het gaat immers om tienduizenden foto's + thumbnails (in, ik geloof, 5 verschillende formaten).

De nadelen waar ik echter tegenaan loop als ik dit besluit om te gooien:
1) 6 sites betekent ook 6 backends
2) de zoek-module (onderdeel van de fotogalerij-extensie) zoekt 'standaard' slechts 1 database door
3) gebruikers-accounts moeten (in geval van 6 sites) ook 6x worden aangemaakt

Is bovenstaand aan te raden? En zo ja; zijn er voor de beschreven nadelen ook oplossingen? Het (deels) koppelen van de databases? En het bijvoorbeeld kunnen schakelen tussen de backends (bridge?)?

Alvast dank!

Ik denk persoonlijk dat de vetraging op je site wordt veroorzaakt door bijvoorbeeld te veel afbeeldingen (die mogelijk ook nog eens volledig camera-formaat zijn) op de voorpagina worden geladen.
Zorg er in ieder geval dat er op de voorpagian alleen thumbnails worden getoond.
Dus geen grote foto's die klein omgerekend worden, want ook dat kost tijd.
Foto-series (vaak in krom Nederlands galerijen genoemd) moeten pas na de voorpagina worden opgeroepen.
Ook daarbij geldt dat er per keer niet te veel foto's geladen moeten worden.
Het laden van foto's van tegenwoordig (vaak al minimaal 5Mb per stuk) kost nu eenmaal veel tijd.

Dat je archief nu groeit naar zulke grote formaten, betekend dat je enorm veel foto's beschikbaar stelt.
Het is een eigen keuze om zo veel data beschikbaar te stellen.
Maar als je rekening houdt met het feit dat foto's inladen de grootste tijd vraagt, kun je misschien met wat aanpassingen op je site, de boel verder toch laten zoals het is.

Ik vond dit artikel nog (Engelstalig) over de mogelijkheid om Joomla! uit te breiden naar meerdere servers.
Mocht je toch die kant op willen, lees het dan even door.

How to Scale Joomla on Multiple Servers

Dank voor je antwoord!

Ik moet je eerlijk zeggen dat je tweede post me m'n pet te boven gaat. Volgens mij worden er op onze server ook geen iSCSI gebruikt. Zoals gezegd steken er daarbij nogal wat nadelen aan het letterlijk opsplitsen van de site over meerdere sites.

Daarin doelde ik dus op alsnog het gebruik van 1 VPS (met meerdere databases).

Om even je eerste post te beantwoorden:

-- De nu ruim 50GB aan data is (buiten de core van het CMS) volledig gebaseerd op de gehoste foto's en thumbnails.
Er wordt echter op geen enkele automatisch gegenereerde pagina gebruik gemaakt van downscaling. Alle afbeeldingen (thumbs) hebben een fixed size. Tijdens het upload-proces van zip-bestanden (batch-modus) worden de afbeeldingen toegevoegd aan een vooraf aangemaakte categorie (boomstructuur). Per foto worden zo'n 5 verschillende fixed size thumbnails aangemaakt (waarvan 2 met watermerk, in cache). Daarbij heb ik de kwaliteit per thumbnail al verlaagd naar 85%

-- De frontpage is het hoofdcategorieën-overzicht van het huidige jaar (2013 dus). 8 thumbnails naast en onder elkaar en that's it.

-- De traagheid wordt (volgens mij) echt bepaald door de database. Het inloggen in de Backend kost namelijk ook nogal wat tijd...

Een snelheidstest: www.websitetest.com/ui/tests/51d7d999b15...d9b3f613f2225e00048e

-- Het is inderdaad een eigen keuze om zoveel foto's beschikbaar te stellen. Het feit is echter, dat andere soortgelijke sites wél gewoon snel laden. Evenals hun zoeksystemen. Die draaien weliswaar niet op Joomla, maar ik heb genoeg Joomla-sites gebouwd die ook gewoon (mega)snel kunnen fungeren.

Dank!

Ik vermoed eerder dat het door je hoster/server veroorzaakt wordt. 50MB voor een database is echt niet veel!

Dank voor je reactie.

Dit is (dit jaar) inmiddels al de vierde aanbieder die we proberen. In dit geval een VPS via het bedrijf Neostrada ( www.neostrada.nl/vps-hosting.html --> Large XL).

In principe was de werking van de site bij de overige aanbieders even traag. Daarom uiteindelijk overgegaan naar een (betaalbare) VPS. Deze optie is verkozen boven het neerzetten van een eigen thuis-server bij de klant.

Is het echt uit te sluiten dat het aan andere factoren zou kunnen liggen? Oorspronkelijk heeft de site een andere achtergrond (repeating pattern), maar die heb ik voor nu even zwart (#000000) gemaakt om het laden zoveel mogelijk tegemoet te komen.

Ik ben geen specialist m.b.t. serverconfiguraties. Maar als ik hem open en de Net optie van Firebug aanzet dan begint het met bijna 7 seconden wachten op de server. Alles wat daarna komt laadt dan zo te zien op normale snelheid.
Ik zie hier nog wel wat fouten, dus het zou kunnen dat het daar mee te maken heeft, maar ik moet daar echt gokken.

Hallo Jaamlo,

Praat eens met hoster, deze kan aan diverse knoppen draaien om je VPS sneller te laten zijn.
De database heeft absoluut geen grote omvang. Met een VPS is het net als met een virtual hosting account, je deelt resources met anderen. Op de harde server staan een aantal accounts, het aantal is afhankelijk van hoe snel je hoster rijk wil worden en het bedrag dat je bereid bent ervoor te betalen.

Het verdelen over meerdere subdomeinen gaat je probleem niet oplossen.

Meer geheugen in de server en snellere schijven zullen eerder soelaas bieden.