PDA

Bekijk Volledige Versie : Wat kan een dedicated server aan



112fryslan
05/03/11, 21:45
Momenteel zitten wij met een grote regionale nieuwssite op een dedicated server die inclusief de website beheerd wordt door de aanbieder van een commercieel CMS. Het rare vind ik dat als er 200 tot 400 bezoekers tegelijkertijd zijn de site erg traag wordt en de foto's laden dan niet of zeer traag.

Omdat wij overwegen om dit jaar over te stappen op een eigen dedicated server met een op maat gemaakt CMS, wil ik graag een aantal dingen weten.

- Is het normaal dat een dedicated server geen 200+ bezoekers aan kan?
- Kan het eventueel ook aan het CMS liggen dat alles traag wordt met een 200+ bezoekers?
- Wat voor dedicated server zouden wij het beste kunnen nemen als wij bij de huidige aanbieder weg gaan?

Wij hebben dagelijks rond de 10.000 bezoekers wat op piekdagen kan oplopen tot 20.000+. Verbruik dataverkeer en schijfruimte heb ik geen idee van omdat dit allemaal geregeld wordt door de huidige aanbieder.

Hoop dat er hier iemand is die wat duidelijkheid kan geven.

WebMeso
05/03/11, 21:49
- Is het normaal dat een dedicated server geen 200+ bezoekers aan kan?

Ligt natuurlijk aan de specs van de dedicated server, in welke taal de website (op)gebouwd is, I/O, databases en veel meer.


- Kan het eventueel ook aan het CMS liggen dat alles traag wordt met een 200+ bezoekers

Dat lijk mij niet, maar daar ben ik niet 100 procent zeker van.


- Wat voor dedicated server zouden wij het beste kunnen nemen als wij bij de huidige aanbieder weg gaan?

Wil je deze dedicated server zelf gaan beheren en als colocatie plaatsen?

Phu
05/03/11, 21:50
Welke CMS word er gebruikt ?
Wat voor server staat het nu op ? een intel celeron is bijvoorbeeld stuk slomer dan een intel xeon processor.
Zijn de fotos compressed of gewoon formaat ?

Er zijn meerdere factoren waaraan het kan liggen.
bijvoorbeeld ijn dat de instellingen gewoon verkeerd staan op de server.
met een beetje finetunen zou je soms al een stuk snelheids winst hebben.

Triloxigen
05/03/11, 22:01
Het kan zeer zeker dat het aan het CMS ligt dat het traag is.
200 tot 400 bezoekers simultaan is zeker niet weinig en dat kan ook zeker effect hebben.
(dat per dag is een heel ander verhaal)

112fryslan
05/03/11, 22:27
Bedankt voor de reactie to nu toe. De cms waar het op draait is Moda. Wat de specs zijn van de server weet ik helaas niet. Wat ik wel weet is dat de fotos fysiek in de database gezet worden en niet een verwijzing zeg maar. Foto's worden bij upload verkleind.

Voor een eigen server is managed toch de beste optie denk ik omdat er bij ons niemand is die zoon server kan beheren.

Phu
05/03/11, 22:39
Als je nu een managed server hebt kan je toch laten kijken door je leverancier waarom dat ding sloom is ?

Bedoel daar betaal je denk ik management kosten voor.

Keizer
05/03/11, 22:43
De problemen die je aangeeft lijkt inderdaad te liggen aan een overbelaste of niet goed geconfigureerde databaseserver. Met een dergelijk bezoekersaantal lijkt het me toch handig een aparte media URL te maken en alle content statisch (gecacht) te serveren.

Voor ons is het ook maar wat gissen als we niet weten welke technieken, software en hardware gebruikt wordt.

rimote
06/03/11, 01:52
Bij een CMS is het een pre om caching/optimalisatie ingebouwd te hebben. Er zijn erg veel technieken toe te passen die de server en het dataverkeer naar de clients ontlasten. Jammer dat er niet meer technische info is. Echt iets nuttigs valt er niet over te zeggen. Hopelijk dat het 'op maat gemaakte' CMS deze eigenschappen wel heeft.

De echte winst moet zoals Keizer oppert komen van het anders inrichten van de omgeving. Caching proxy lost al veel op.


- Wat voor dedicated server zouden wij het beste kunnen nemen als wij bij de huidige aanbieder weg gaan?

Met dit bezoekersaantal, en ik hoop ook waarde, zou ik niet op één dedicated gaan zitten (managed of niet). Minimaal twee servers voor redundantie (dat kunnen best simpele dell r210 zijn, mits de boel goed wordt opgezet). Of een cloud oplossing om de vaste kosten en initiële kosten laag te houden.

De servers moeten draaien, de bezoekers moeten tevreden zijn en u moet goed kunnen slapen. Zeker met dit bezoekersaantal: zoek iemand die er verstand van heeft en die voor u de setup en het onderhoud doet en ook mee kan groeien als u dat doet.

xaban
06/03/11, 08:20
Dit zijn helemaal geen schokkende aantallen, valt allemaal harstikke mee, een tweede server vind ik dan ook (zeer) overdreven.

Als het bij 200-400 bezoekers traag wordt zou ik eerder naar het gebruikte CMS systeem kijken dan naar de specificaties van de server (ik neem aan dat het geen verouderde Pentium CPU + 2GB memory server is).

Ik wil je best wel helpen mee zoeken naar het probleem, echter heb ik wel toegang nodig tot de server.

Succes!

rimote
06/03/11, 13:41
@Xaban Ik ben het geheel met je eens dat het hier niet over schokkende aantallen gaat. Maar ik vind wel dat het voor een website met 10.000 tot 20.000 bezoekers per dag en tot 400 simultane bezoekers er waarschijnlijk een bepaalde waarde aanwezig is die het waard is te verzekeren met een redundante setup. Dat je het (zeer) overdreven vindt dat ik dit adviseer, mag je natuurlijk zelf weten.

Een goede setup in een cloud hoeft tevens niet meer te kosten dan een dedicated server, terwijl de redundantie dan goed geregeld is. Daarnaast lijkt een beetje investeren niet het probleem. Adviseren om op één server te gaan zitten lijkt mij in dat geval niet juist.

Nogmaals voor de duidelijkheid, het gaat hier om betrouwbaarheid en redundantie. Het gaat er niet om dat een enkele server het niet aan zou kunnen.

Ramon Fincken
06/03/11, 14:20
wat is de URL? Gebruiken jullie caching of andere optimalisatie? Zijn de indexen wel correct in de database?

Bart L
06/03/11, 14:21
Duidelijk een cache probleem. Dit soort aantallen kunnen normaal (bij een recente server) prima op 1 omgeving. Ik ben het uiteraard wel mee eens dat je dit soort dingen zelden op 1 omgeving moet willen zetten, maar dat is een andere discussie. Met 2 servers zul je namelijk ongetwijfeld hetzelfde probleem overhouden.

Gouden regel is dit soort omgevingen. Alles cachen wat niet realtime hoeft worden aangeboden. Dit kan ook met bijvoorbeeld temp tabellen in Mysql.

Wij hebben omgevingen tot 30 miljoen requests per dag in beheer, en dat gaat prima op een "paar" servers.

Snel I.S.
10/03/11, 16:56
- Is het normaal dat een dedicated server geen 200+ bezoekers aan kan?
Dit ligt er maar net aan wat de specificaties zijn van de dedicated server, Dataverkeer speelt hier ook een grote rol ik mee!

- Kan het eventueel ook aan het CMS liggen dat alles traag wordt met een 200+ bezoekers?
Ligt eraan wat er word opgeslagen van de bezoekers die kijken.
- Wat voor dedicated server zouden wij het beste kunnen nemen als wij bij de huidige aanbieder weg gaan?
Voor het beste aanbod kun je naar een ISP naar keuze gaan, dit voorleggen. Dan kunnen zij je wel verder helpen met een dienst naar keuze!

Geert-Jan
10/03/11, 18:14
- Is het normaal dat een dedicated server geen 200+ bezoekers aan kan?




Dataverkeer speelt hier ook een grote rol ik mee!


@Snel, wil je me dat eens uitleggen?

Keizer
14/03/11, 01:20
Helaas was de link vanaf Geenstijl weer een doodoener voor je server, volgens mij heeft ie er geruimte tijd uit gelegen...

Heb je al antwoord op bovenstaande vragen?

Vic D'Elfant
14/03/11, 09:38
Neem aan dat er op dit moment geen topdrukte is op de site, maar hij is nog altijd niet vooruit te branden. Afhankelijk van of 112fryslan al een oplossing heeft gevonden, lijkt me dat er twee zaken het belangrijkste zijn om te weten:

Wat zijn de specificaties van de huidige server. Als dit een monster van een server is, weet je zeker dat het aan de programmatuur ligt. Is het een server met single-core Celeron processor, ligt het daar aan;
Wat is de technische kennis van 112fryslan, voordat we hier met moeilijke termen gaan gooien.

Foto's opslaan in de database is sowieso een gruwel, bestanden horen daar niet thuis. Als je ze als bestanden opslaat kun je ze uiteindelijk ook onderbrengen op een aparte server (of CDN, maar dat is van latere zorg).