Hi,
We have planned to have a 100 displays over multiple locations with a single CMS. So, it might result in a huge bandwidth consumption when all the clients simultaneously download the content at the same time from the server. So, is there any way to overcome this problem ? Shall we use a separate content manager for each location (ie; we will be downloading content from server to this particular manager or client and other clients will be downloading content from manager) ?
Thank you.
Even a pretty modest server should be able to deal with 100 clients downloading a few files.
In reality assuming you have a collection interval of 5 or 10 minutes (which would be about the minimum you’d want in a production environment) then the clients will stagger that download over a longer period as they won’t all connect together.
Or, you could throttle the throughput to the CMS from each client with a firewall appliance. Something like PFSense could do that easily.
Hi,
Can you explain the bandwidth utilization of the server ?
Explain what exactly about the bandwidth the server uses?
1.7.2 provides very detailed logging in the CMS for client bandwidth usage so you can see exactly what is being used by which calls to the webservice. Is that not sufficient?
Alex, my bad. I am sorry for that.
One more help.“you could throttle the throughput to the CMS from each client with a firewall appliance. Something like PFSense could do that easily.” I did not understand
I mean that you could put a firewall appliance in front of your web server such as PFSense:
https://www.pfsense.org/
That appliance can rate limit connections between your clients and the web server, but I really don’t think with 100 clients only that would be necessary (assuming we’re talking about hosting on a proper server in a data centre with carrier grade bandwidth availability and not running this off a 3G dongle!)
Thanks Alex. We are planning to connect about 150+ displays. So we are worried about the bandwidth utilization if all displays starts downloading the media at the same time. Any suggestions on this? Are you telling the media will not be downloading at a time? Is it like one display will download media after the other one downloaded completely?
They won’t queue up waiting for the one before as you suggest, but they won’t all connect at the exact same moment either - but how staggered they are depends on the collection interval you set on the Players.
If you want to throttle the bandwidth to each client or rate limit their connections then you would need to put additional software (eg PFSense or another firewalling or ratelimiting device) in front of your webserver.
We run very large instances of Xibo for customers, and I’m saying that assuming you’re using datacentre grade equipment with sensible bandwidth to the CMS, then even 150 clients won’t be an issue assuming you’re not downloading hundreds of megabytes of data on each collection.
The only way to be sure is to test it with 10 Players and scale it out from there.
If however you’re going to have 150 clients polling every 10ms for your proposed volume control then you will certainly have problems with the number of worker threads/processes in the web server being exhausted.
Couldn’t agree more!! Exactly relevant to my last message in the volume control topic!
Yeah, we understood the problem. We will test for 10 players first and then we will check the issues coming.Thanks for your support Alex and Dan 
Hi
If we increase the download speed in the client (i,e) increasing the chunksize to 1024kbps will it cause any problem with bandwidth ? We are having collection interval of 60 seconds and nearly 150 displays.
Thank you
It will decrease the overall number of connections to the CMS, but it will also increase the amount of work the CMS will have to do to service each request, and increase the amount of RAM it will require to run. Those kinds of modifications need you to TEST with actual reproducable benchmarks to see the effect on your infrastructure.
You would be much better to use the HTTP download ofload functionality in Xibo such that the webserver sends the files down over HTTP rather than via the SOAP service as there’s a much lower overhead, but only assuming that you have reliable connections between your CMS and clients since resuming broken downloads isn’t supported in that configuration.
Alex,
Could you please explain a little bit more ?
There is a setting called “File Download Mode” in the CMS which converts all downloads to HTTP rather than through SOAP.
This is much more efficient because each file only needs 1 connection rather than a chunked download through PHP.
This uses sendfile mode in apache and nginx and assumes that is configured appropriately.
Thank you very much Dan 