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