Score:0

Is 250Mbs on a cheap VPS enough for 500 CCU listening to radio stream?

tr flag

I'd like to use a cheap VPS hosted by OVH, France (1 vCore, 2 GB RAM, 40 GB SSD NVMe, 250 Mbps unmetered) to host an icecast server which will be used for an event this month. There will be up to 500 CCUs listening to the 128 kbps audio stream.

based on my reading of this article, it seems to me that 250 Mbps should be enough to respond to the load, but i haven't got any experience in managing this kind of problem.

My reasoning is that 128kb*500CCU + 10% overhead = approx 70 Mb/s.

I'm also wondering if the 250 Mbps unmetered supplied by OVH are guaranteed, or whether the load on other services hosted by other clients using the machine could have an impact on performance. (I asked OVH already but they weren't especially helpful)

thank you for your insights! samuel

UPDATE

I have set up a load test scenario with the script described in the link above.

#!/bin/sh
#

# max concurrent curls to kick off
max=600
# how long to sleep between each curl, can be decimal  0.5
delay=1
# how long to stay connected (in seconds)
duration=1800
# url to request from
URL=<theURL>

echo "Start load test"

while /bin/true
do
count=0
while [ $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
   let count=$count+10
   echo "Added 10 clients, now at $count clients"
done
wait
done

before launching the script on VPS1 (the "client" machine), i opened a window to monitor network usage using slurm on my network interface on VPS2 (the "server" machine, where the icecast2 server is located), as such :

slurm -i eth0

i also opened a window to monitor CPU usage of icecast (on VPS2), as such :

top -p <PID OF ICECAST>

and launched the script while listening to the radio stream. Everything went fine, i didn't hear glitches, and the CPU usage (6% at 600 CCU) is very reasonable (also the network usage is much lower than what i expected, peak usage was at 17MBs), so i guess my setup passed the load test!

Thank you for your help.

ng flag
You conflate `b(it)` and `B(byte)` (capitals). Can you edit your question and be explicit with `kbit`, `Mbit` and `Mbyte`.
Samuel Hackwill avatar
tr flag
thank you for your comment, i've edited my original post.
Score:1
de flag
TBR

In pure numbers, it indeed is well enough.

In reality, it's not guaranteed. As you mention, the 250MBit/s is not guaranteed/committed. Also there will be effectively different achievable bandwidths to/from different ISPs/destinations. As the traffic will exit OVH via various interconnects such as peerings and upstream providers.

In practice the most practical approach is going to be to keep an eye on things and to listen to user feedback. One fairly common sign of congestion would be if you start to see many/all listener clients lag behind a lot in the Icecast admin interface. Notice that some or a few are most likely always to lag behind for a variety of other reasons and should be safe to ignore.

The other option is usually reserved to large scale professional deployments: Multiple servers, each with committed bandwidth.

Samuel Hackwill avatar
tr flag
Thank you so much for your feedback! i've also come across [this post](https://serverfault.com/questions/350454/how-do-you-do-load-testing-and-capacity-planning-for-web-sites) which advises that the only way to be sure is to simulate the load scenario. I'm going to try that next!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.