Genoeg bandbreedte webhosting

[Anoniem: 201557]

Hoi allemaal,

Een potentiële klant heeft mij gevraagd een dynamische website te maken (HTML5, PHP/MySql, Javascript, AJAX en CSS3) met daarbij het verzoek om veel MySql database informatie "Live" weer te geven aan de bezoekers via bv. HTTP Requests in Ajax met als return data uit de Database via bijv. PHP-bestanden. Images worden geladen uit folders op de server zelf.

Veel van de scripts (+/- 50 tot 250 afhankelijk van het aanbod) zullen iedere seconde tot halve seconde de tekstuele informatie (+/-) moeten verversen die met CSS3 is opgemaakt en images moeten weergeven uit de server folder (dit zijn statische images, dus worden maar 1x geladen)

De opdrachtgever hoopt op 5.000 - 10.000 bezoekers per 24 uur te zijner tijd maar kunnen er ook meer worden...

Nu vraag ik me het volgende af:

• Kan een gemiddelde webserver (shared of dedicated) wel zoveel HTTP Requests aan? Bijv. 10.000 x 24uur x 60min x 60 aanvragen per seconde of 120 aanvragen per seconde = 864.000.000 HTTP request per 24 uur (iedere seconde een request) of 1.728.000.000 per 24 uur (iedere halve seconde een request)
• Indien bovenstaande toch mogelijk is, wat dat zal betekenen voor de stabiliteit van de hostingserver
• Komt de snelheid en toegankelijkheid van de hostingserver in gevaar omdat er veel dataverkeer is
• Kan de gemiddelde browser van bezoekers wel zoveel (50-250) verzoeken tegelijkertijd doen? Google verteld me iets anders namelijk als ik het goed begrijp..

Ik hoop dat iemand mij hier wat meer over kan vertellen, alvast bedankt!

Groet Niek

[Ramon]

Hangt er compleet vanaf hoe je applicatie in elkaar zit. Het is voor een beetje webserver geen enkel probleem om bijvoorbeeld 120 cached (ajax) requests per seconde te serveren. Maar als je ze niet cached en ingewikkelde sql queries uitvoert bij elke request wordt het al lastiger.

Wat de browser betreft, ik heb het nooit geprobeerd maar ik denk dat die het wel "wat lastiger" gaat krijgen bij 120 ajax request per seconde.

Maar als je ons verteld wat er precies getoond gaat worden en wat het doel is van de site kunnen we denk ik beter meedenken?

[Anoniem: 91626]

Over de werkelijke aantallen kan ik je niet veel vertellen. Maar sommige vragen zijn wel wat simpel. Zoals":

wat dat zal betekenen voor de stabiliteit van de hostingserver

Servers zijn machines die als je ze genoeg voer geeft en een geconditioneerde ruimte ze prima binnen hun specs vele errors kunnen maken zoals het hoort als de content fouten bevat. Dus als je content statisch is zal er vrij weinig doom editing "de boel verzieken natuurlijk. De vraag is hoe groot de datapackets worden die richting de gebruikers gaan en of de server dit ook in zulke grote getallen in z’n eentje kan en de netwerk snelheid moet ook voldoende zijn. Is dit slechts 1 mb per persoon voor "huidige stand info" is dat wat anders dan als je bv de hubble pics van Nasa gaat opzoeken via hun browser en downloaden natuurlijk.
Het mooie is dat je niet in één dag zomaar 10k bezoekers krijgt dus je kan gaandeweg vrij goed controleren waar de bottleneck zit en hier meer 'capacity' aan geven en zoals Ramon zegt natuurlijk Cashen die hap!

[jep]

Dataverkeer of bandbreedte zal nooit je bottleneck worden bij dit soort dingen. Je webserver, php en caching config zijn cruciaal. Op basis van die getallen zie ik voor een dikke server geen probleem. Denk alleen aan de toekomst wanneer het zal toenemen. Je zult dan voorbereid moeten zijn op verdere opschaling van je servers (centrale storage, meerdere databaseservers).

Keywords; Nginx (webserver), Memcached (!), APC op PHP en voldoende werkgeheugen.

[Craven]

Even afgezien van alle andere info kan je dit natuurlijk niet zo stellen:

Kan een gemiddelde webserver (shared of dedicated) wel zoveel HTTP Requests aan? Bijv. 10.000 x 24uur x 60min x 60 aanvragen per seconde of 120 aanvragen per seconde = 864.000.000 HTTP request per 24 uur (iedere seconde een request) of 1.728.000.000 per 24 uur (iedere halve seconde een request)

Ik weet niet of de bezoekers internationaal zijn of uit 1 tijdszone gaan zijn maar je kan meestal niet stellen dat de gebruikers zich over de gehele dag verspreiden. En dan moet je ook nog rekening houden met het thema van de site. Puur privé word 's avonds natuurlijk beter bezocht dan zakelijke websites.

[Anoniem: 201557]

Allereerst allemaal thnx voor de replies!

@ Ramon: Vanwege een geheimhoudingsplicht kan ik nog niet teveel ins-en outs geven wat de website exact gaat doen...Altijd fijn, ik weet het...

Het probleem is dat de return-informatie in mijn optiek niet gecached kan worden aangezien deze dynamisch is. Deze veranderd continu door input van andere gebruikers wat het "Live" effect van de website dan ook is. De informatie die waarschijnlijk getoond wordt gegenereerd door een simpele SELECT-query waarbij op een ID gezocht wordt en gesorteerd op een timestamp waarde.

Een mogelijk scenario ter verduidelijking:

• Gebruiker opent een PHP pagina (pagina 1) met gecontroleerde variabelen uit de gevraagde URL, bijv. http://www.example.com/php-bestand.php?id=1
• Pagina 1 geeft gebruikers de mogelijkheid om input te geven die in de database wordt weggeschreven na controle van waarden
• Aan de hand van de variabelen wordt middels bijv. Javascript een HTTP Request gestart die iedere (halve) seconde een andere PHP pagina (pagina 2) aanroept met simpele variabelen die pagina 1 meegeeft. Bijv. http://www.example.com/aj...?sid=1&information=active
• Pagina 2 gebruikt de variabelen om uit de database via een Select-query (met Where and Sort) tekstuele info weer te geven die op pagina 1 kan worden ingegeven door de gebruiker. Maximale rows die getoond worden zal ongeveer 15-25 rows zijn. De variabelen worden wel gecontroleerd door pagina 2 op geldigheid via PHP
• De resultaten van de SELECT query worden opgemaakt met CSS3

Hoop dat dit wat meer duidelijkheid geeft.

@ Craven: Goed punt! Om 3 uur 's nachts zal het idd wat minder druk zijn Lol
@ Larsiano: Begrijpelijk
@ Jep: Helpvolle keywords, thnx Alhoewel ik nog nooit met een Nginx server gewerkt heb volgens mij maar Google is my best friend