Scalability of Kurento 6.6.0

[Michaël]

Hi,

We are using in our solution Kurento 6.5.0 to record videos. 

The Kurento Media Server is hosted in an Amazon Elastic Compute Cloud (EC2) whose setup is: 

Max. bandwidth (Mbps): 450

Expected throughput (MB/s): 56.25

Max. IOPS (16 KB I/O size): 3,600

As we are expecting to handle a large number of simultaneous video recording (up to 500), we would like to know how scalable Kurento is, for example: 

• How many simultaneous video recording can be efficiently handled by a single Kurento instance? / How many concurrent streams should Kurento be able to handle ?
  
• Is my EC2 setup enough to cover this scalability and if not, which EC2 instance type whould you advice me  ?
  

Thanks,

[Michaël]

There's a typo in the first sentence, we are using Kurento 6.6.0

[Michaël]

I guess video resolution constraints may have an impact on the scalability issue, so I post here our setup:

maxWidth: 320,

maxHeight: 240,

maxFrameRate: 15,

minFrameRate: 15

On Wednesday, September 21, 2016 at 1:04:40 PM UTC+3, Michaël wrote:

[Michaël]

Hi,

Sorry for the follow-up but our company would like to know if Kurento will be the good solution to cover our needs (from a scalability/robustness perspective).

Can anyone from the Kurento Team assist on that? 

I can provide any further information that you may need.

[Ivan Gracia]

Please read this recent blog post. At the end of the post, there's an email address where you should address that query.

Cheers,

Ivan Gracia

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[trank...@gmail.com]

Hi,

Working for a big ISP, I'm very interested in the answer to the original question. Scalibility is a very important topic.

I don't understand why you kick out this important "public" question.

So I insist: Do you have a feature, like RTP forwarding in janus, to allow infinite horizontal scalability (when number of VMs is not an issue like in my case)  ?

FYI I'm working on 1 TO N use case with 1000 < N < 10 000

Thanks in advance for your answer

Julien

Ivan Gracia

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

[Andrey Pospelov]

Is it possible to address this here, Im also interested inthis,but I'd like to use openstack not amazon

Ivan Gracia

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

[trank...@gmail.com]

Hello Andrei,

I think you can forget openstack ATM : this techno is not ready for real time services and there are many packets losses everytime

I have 2 hugh openstack cloud: 1 based on openstack/Neutron and the other and openstack/Opencontrail

both are loosing packets between 1 and 7% (and sometimes more) which is 1000x too much

You can check it by yourself using iperf3 (and check with pcap traces if you don't trust iperf)

to check @500 Mbits for instance

#iperf3 -c IP_OF_YOUR_DST_IPERF_SERVER -u -b 500M -t 10 

be sit down when you will see the results of packets droped :)

J-

[Andrey Pospelov]

Thank you for the info. I can't check now. Openstack is 6 years old and even 1% loss is not ok. Is this with the latest versions of everything?

I planned to use CephFS to store recorded videos also, not only store but just mount the CephFS to ubuntu and write files directly to it.

Are there any news about this?

[Ivan Gracia]

If you read the whole post, you should understand why I'm forwarding you there. Our solution to that was elasticRTC, so please let me quote here the important part there that refers to it, so you don't need to read the whole thing if you don't feel like it. Long story short ;-)

If you're building on elasticRTC, Twilio wants to work closely with you to make sure you can migrate your use cases to Twilio when the time is right. Please contact Twilio if you have any questions about migration or support at kur...@twilio.com.

Cheers,

Ivan Gracia

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

[Lokesh Lal]

We have done some work to scale the kurento using master slave method. The topology depend upon the kind of use case targetted. There could be master-process-slave topology as well, depending upon kind of processing required to the incoming stream. Pipelines were build, saved in cache and assigned to the rooms. On an event of failure of kurento instance, application layer will take responsibility of reconnect clients with the new/available kurento instance. And the performance was ok.

We grouped servers and tag the groups. Then let the pipeline decide which server group they will be using.

[Ayaan]

Hi Lokesh - Great idea! Can you share some code examples and some notes on how to accomplish this?