Server with application per user or few uniwersal applications

Hello everyone

We are working on some service that will allow our users to put up a stream from IP camera on the internet.

Now from wowza server side we will need to manage those streams in some organised way.

Currently we are considering 2 ways of doing it:

  1. We will have few different applications preconfigured on server, and we will connect user stream to selected applications (depends on needs, for example 1 origin app and multiple edge apps)
  • easy for manage

  • can have our own application architecture and extend it to multiple servers, do migrations etc

  • hard to track single user/stream usage

  • no separation between users

  1. We will create an different application for every user, and will configure it with his needs in mind
  • have very nice metrics built in wowza

  • application per user means we can set it exacly like user wants

  • separation betwen users

  • harder to manage

  • can be like 100 or applications running on 1 server (some users will have 1 stream only)

  • harder to extend to multiple servers

So those are pluses and minuses we figured out (we might be wrong with some tho).

And there are some questions:

Will wowza be able to effectively handle high amount of applications per server ?

Is there any good addon for metrics like preferably per stream bandwidth and resource usage ?

and finally:

What are so called good practises for that kind of service ?

I would appreciate any feedback and help for this topic.

Best regards

Adam

Hi Adam,

Either option could work. You’ve highlighted the swings and roundabouts of the two approaches yourself. Having 100+ Wowza applications in one instance is not unknown. It does give you the individual monitoring and long term stats as you mention. It will add load to the server of course, and if all applications are active at the same time then you’ll need to ensure that the backend housekeeping stuff such as updating stats database etc is able to operate. Fast (SSD) IO helps a lot there.

The alternative of having all streams in one application does as you also mention help with management and migration etc, but you’ll lose individual monitoring and stats history available via the Engine Manager. There are third party reporting tools that can parse Wowza log4j log files, so that can be mitigated in that way. A quick Google of “wowza +reporting +logs” should show a few.

I’d say good practice would firstly be to ensure that it is manageable and you have the physical resource and network infrastructure in place to prevent any bottlenecks. We do provide a load testing tool that can be useful to flush this out. If creating 100+ applications then another tip is to set the [instance-path]/conf/Application.xml as your template conf file and then when you create new apps this will be used as the basis so you don’t need to keep reapplying custom modules/properties/specific Playback Types etc to each new app. If your clients are going to be RTMP only then you can also disable the HTTP Playback Types to remove unneeded packetizing, and even look at setting the StreamType to rtp-live which can help a lot with regards to network utilization by dropping connections to the IP camera source if clients are not connected.

There are probably a number of other things that could be suggested, but I’d personally just start small, test the results and build up from there.

Paul

Hello,

The Wowza REST API is currently available in Wowza Streaming Engine. You can also find some useful REST API examples in the “Server Administration: REST API Query Examples” forum section.

Regarding the restriction of the stream names that can be used for publishing to a particular application, you can take a look at the “How to limit the streams to Wowza server from Encoders” forum thread for some useful information.

Zoran

Hi Adam,

Either option could work. You’ve highlighted the swings and roundabouts of the two approaches yourself. Having 100+ Wowza applications in one instance is not unknown. It does give you the individual monitoring and long term stats as you mention. It will add load to the server of course, and if all applications are active at the same time then you’ll need to ensure that the backend housekeeping stuff such as updating stats database etc is able to operate. Fast (SSD) IO helps a lot there.

The alternative of having all streams in one application does as you also mention help with management and migration etc, but you’ll lose individual monitoring and stats history available via the Engine Manager. There are third party reporting tools that can parse Wowza log4j log files, so that can be mitigated in that way. A quick Google of “wowza +reporting +logs” should show a few.

I’d say good practice would firstly be to ensure that it is manageable and you have the physical resource and network infrastructure in place to prevent any bottlenecks. We do provide a load testing tool that can be useful to flush this out. If creating 100+ applications then another tip is to set the [instance-path]/conf/Application.xml as your template conf file and then when you create new apps this will be used as the basis so you don’t need to keep reapplying custom modules/properties/specific Playback Types etc to each new app. If your clients are going to be RTMP only then you can also disable the HTTP Playback Types to remove unneeded packetizing, and even look at setting the StreamType to rtp-live which can help a lot with regards to network utilization by dropping connections to the IP camera source if clients are not connected.

There are probably a number of other things that could be suggested, but I’d personally just start small, test the results and build up from there.

Paul

Hey Paul, if you create a application using the REST API, can the config template still be copied to the new Application ?

We are looking to do the same, create unique-individual streams for our userbase (each user can stream only to his own) instead of a current open-stream system, we will be streaming from RTMP/HLS but too confused to think how to go about this. Even if you create a unique application per user, they can still stream to any stream name (create multiple streams) instead of a specific stream (single, like twitch/youtube)


Small update

So I did a bit of digging around and seems the best option for the above scenario is one application per user (due to freedom of custom settings and stats), although managing it would be a pain. Is there any update on when the full REST API would be available ? I think for a public platform, it would be better to use the APIs to do all the automation tasks (creating a new application when a user registers) and storing all this data of wowza related config mapped to that user’s data in our own database aswell (to manage and work with API more easily)

However, the problem would have still remained that anyone could have streamed to a user’s channel as long as they know the application name (twitch/youtube creates a random long stream name/key for this and this is what I want to do aswell)

So for that part, I thought a solution can be using user/password authentication per application, which I found about in the docs

However, the other part of the problem remains, the user can still do stream using any stream name to that application (after authentication)

So even if though the stream name we have configured our frontend/api/player to use is stream1, the user can stream using names stream2 or stream3 which even though they wont be used in our API/players, the server would still use resources to listen to them, transcode them and for the DVR/VOD