Usage Limits & Recommendations

currently, customers in hotmic are set up with their own environments, configured to their own scaling needs file sizes file recommendation limit profile picture png/jpg of approximately 256x256 (between 200 and 500 pixels across) 1028x1028, smaller is better thumbnail, break slate, end slate picture png/jpg of 1280x720 files will be resized to these dimensions limits all limits can be increased by talking to our team constraint limit max simultaneous live streams 10 max simultaneous vod streams no limit max viewers per stream 250,000 max simultaneous viewers across all live and vod streams 250,000 max hosts per stream 6 (or 5 + media sharing) for additional usage, please contact us recommendations all limits can be increased by talking to our team constraint limit host machine we recommend a pc, mac, or linux machine roughly equivalent to a 2018 macbook air at least 8gb ram 2+ cpu cores with a base performance of 1 6+ ghz and turbo performance of 3 0+ ghz a gpu performance is likely to be good on even lower powered devices, although we don't recommend it successful tests have been made on machines including low powered 2018 chromebooks and laptops running with gpu disabled minimum download speed minimum dedicated 1mb/s down minimum upload speed minimum dedicated 1mb/s up microphones headsets with microphone for improved sound quality and privacy usb echo canceling speakers for meeting room environments browser chrome or edge scalability and load testing as each customer for hotmic has primarily dedicated resources, we know how our default configuration will respond under load, and can give you information about the breaking points and effects at scale hotmic has conducted and regularly conducts extensive load testing of the hotmic platform on our default cluster setup, we see normal performance on clusters running up to 480,000 concurrent users joining a stream and interacting with the stream our suggestion is to speak to hotmic if you expect traffic to go beyond 250,000 concurrent users across all your streams this is the high level structure of hotmic's infrastructure graph td; web browser >stream composer; stream composer >rtmp; rtmp >hls; hls >video cdn; join session >hotmic sdk; video cdn >hotmic sdk; chats >hotmic sdk; polls >hotmic sdk; the web browser of the host this must have minimal requirements to compose the stream on the local device, receive chats and polls while we have tested in devices as weak as a low powered 2018 chromebook, we recommend something more powerful, such as a recent macbook air or higher class device (pc, mac, or linux) note that the number of viewers has limited impact on the host machine, for example polls and chats are aggregated and refreshed on intervals in order to maintain performance stream composer this is a hotmic server that combines all the elements of the feed and outputs an rtmp this can handle up to 6 inputted streams hosts or media playing this is not affected by viewer behavior rtmp to hls our pipelines constrain the number of simultaneous hls conversions, and this is by default limited to 10 per account we can increase this with notice video cdn we house videos in cloudfront, which should handle effectively unlimited scale users in the sdk join a session then recieve the video from the cdn, plus chats, polls, and other updates we recommend contacting us if you plan on having more than 250k simultaneous users so we can help support normal usage patterns our standard cluster will start to show significant performance degradation beyond 480,000 but we would increase scale once usage gets beyond 250,000 concurrent users we requrest 2 week advance notice to scale beyond our standard cluster some specifics on the components the server recieving chats we have tested up to 10,000 chats per minute at these levels, the app ui feels overwhelming, but the applications does not break a typical stream would have <10% of users chatting, so this should support up to 1m concurrent users like other limits, this load is the same whether on 1 stream or many streams, the backend poll service incurs the same load polls polls have been tested up to 5,000 polls answered in 1 minute beyond that point, and poll delivery will be delayed for processing a typical stream would have <10% of users answer polls, so this should support up to 500k concurrent users on streams with active polls like other limits, this load is the same whether on 1 stream or many streams, the backend poll service incurs the same load the users entering the stream this is almost always the highest load event on our servers, as users who are notified of a stream typically join within a 5 minute period we have tested with minimal impact up to 480,000 users joining over 5 minutes we recommend talking to us if you expect more than 250k maximum concurrent and we stongly discourage any usage over 480k concurrent users unless your cluster has been upgraded to support it testing while we run load tests in conjunction with almost every deployment, here are a sample of recent load test results most recent public load tests april 2023 we ran a series of load tests outside our normal deployment proces on april 2023 to find the breaking points for a standard configured instance of hotmic for a customer in these tests, we found the overall chokehold occurs around 4,500 requests per second in most cases, more than half the requests for a stream are to join the stream this ends up meaning in practice that approximately 2,000 concurrent users could join a stream per second joining a stream is the event that has the most load on the system these results matched prior tests for a typical stream, we see joins occur around 5 minutes from the time of a given alert this means the maximum theoretical joins over a 5 minute period would be 600,000 (5 x 60 x 2,000) this limit is across all streams, and is not affected by the number of concurrent streams in other words, 10,000 viewers simultaneously joining 10 streams would have the same load impact on hotmic as 100,000 viewers simultaneously joining 1 stream this can be seen in this graph, which the blue line represents the number of virtual simulated users until 500,000 users or so, response times look good after 500,000 users, we see response times increase towards unacceptable levels and some timeouts occur