Puncte:0

Este suficient 250 Mbs pe un VPS ieftin pentru 500 CCU pentru a asculta fluxul radio?

drapel tr

Aș dori să folosesc un VPS ieftin găzduit de OVH, Franța (1 vCore, 2 GB RAM, 40 GB SSD NVMe, 250 Mbps necontorizat) pentru a găzdui un server icecast care va fi folosit pentru un eveniment luna aceasta. Vor exista până la 500 de CCU care vor asculta fluxul audio de 128 kbps.

pe baza citirii mele despre Acest articol, mi se pare că 250 Mbps ar trebui să fie suficienți pentru a răspunde la încărcare, dar nu am experiență în gestionarea acestui tip de problemă.

Raționamentul meu este că 128kb*500CCU + 10% overhead = aproximativ 70 Mb/s.

De asemenea, mă întreb dacă cei 250 Mbps necontorizati furnizați de OVH sunt garantați sau dacă încărcarea altor servicii găzduite de alți clienți care folosesc mașina ar putea avea un impact asupra performanței. (Am întrebat deja la OVH, dar nu mi-au fost deosebit de utile)

mulțumesc pentru opiniile tale! samuel

ACTUALIZAȚI

Am configurat un scenariu de testare a încărcării cu scriptul descris în linkul de mai sus.

#!/bin/sh
#

# max bucle simultane pentru a începe
max=600
# cât timp să dormi între fiecare buclă, poate fi zecimală 0,5
întârziere=1
# cât timp rămâneți conectat (în secunde)
durata=1800
# URL de la care solicitați
URL=<theURL>

echo „Începe testul de încărcare”

în timp ce /bin/true
do
count=0
în timp ce [ $count -le $max ]
do  
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   curl -m $duration --silent --output /dev/null „$URL” &
   [ "$delay" != "" ] && sleep $delay
   lăsați să numărați=$count+10
   echo „S-au adăugat 10 clienți, acum la $count clienți”
Terminat
aștepta
Terminat

înainte de a lansa scriptul pe VPS1 (mașina „client”), am deschis o fereastră pentru a monitoriza utilizarea rețelei folosind slurm pe interfața mea de rețea pe VPS2 (mașina „server”, unde se află serverul icecast2), ca atare:

slurm -i eth0

De asemenea, am deschis o fereastră pentru a monitoriza utilizarea CPU a icecast (pe VPS2), ca atare:

sus -p <PID OF ICECAST>

și a lansat scenariul în timp ce asculta fluxul radio. Totul a mers bine, nu am auzit erori, iar utilizarea procesorului (6% la 600 CCU) este foarte rezonabilă (de asemenea, utilizarea rețelei este mult mai mică decât mă așteptam, utilizarea maximă a fost de 17MB), așa că cred că configurația mea a trecut testul de sarcină!

Vă mulţumesc pentru ajutor.

drapel ng
Combinați `b(it)` și `B(byte)` (majuscule). Puteți să vă editați întrebarea și să fiți explicit cu `kbit`, `Mbit` și `Mbyte`.
Samuel Hackwill avatar
drapel tr
mulțumesc pentru comentariu, mi-am editat postarea inițială.
Puncte:1
drapel de
TBR

În numere pure, într-adevăr este suficient de bine.

În realitate, nu este garantat. După cum menționați, 250MBit/s nu este garantat/committed. De asemenea, vor exista efectiv diferite lățimi de bandă realizabile către/de la diferiți ISP/destinații. Deoarece traficul va ieși din OVH prin diverse interconexiuni, cum ar fi peering-uri și furnizori din amonte.

În practică, cea mai practică abordare va fi să fii cu ochii pe lucruri și să asculți feedback-ul utilizatorilor. Un semn destul de comun de congestie ar fi dacă începi să vezi că mulți/toți clienții ascultători rămân mult în urmă în interfața de administrare Icecast. Observați că unii sau câteva sunt cel mai probabil să rămână întotdeauna în urmă dintr-o varietate de alte motive și ar trebui să fie în siguranță să fie ignorate.

Cealaltă opțiune este de obicei rezervată implementărilor profesionale la scară largă: servere multiple, fiecare cu lățime de bandă angajată.

Samuel Hackwill avatar
drapel tr
Vă mulțumesc foarte mult pentru feedback! De asemenea, am întâlnit [acest post] (https://serverfault.com/questions/350454/how-do-you-do-load-testing-and-capacity-planning-for-web-sites) care sfătuiește că singura modalitate de a fi sigur este de a simula scenariul de încărcare. O sa incerc asta mai departe!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.