Hello Max,
sorry for the delay, will try to answer your questions
1) According to user reports it is possible to have ~50 participants
in one room, BUT
a) you need to use room of type "Restricted"
b) I only have reports regarding 10-15 people with video, others
are audience
To reduce network requirements per server you might want to set up clustering
I would add nodes to the cluster in case server bandwidth will be exausted
AFAIK there is no limit for maximum duration
maximum download-size can be configured via OM admin:
http://openmeetings.apache.org/GeneralConfiguration.html
(max_upload_size)
I believe bottleneck is server bandwidth
2) I'm not aware of any browser specific issues
I would recommend to use latest release 3.1.3 due to bug fixes and
stability improvements
3) Is it still reproducible with latest release? do you have steps to
reproduce? I have created JIRA issue to track this:
https://issues.apache.org/jira/browse/OPENMEETINGS-1482
But I still need steps to reproduce ....
4) I'm afraid it is currently not possible, I plan to add some
restrictions in 3.1.4
On Mon, Oct 3, 2016 at 7:38 PM, Max Mustermann
<[email protected]> wrote:
> Hello OpenMeetings-Team,
>
> I would highly appreciate gathering some answers to some
> OpenMeetings-questions i worked out for you, maybe you can help a little.
>
> We are running following setup:
> * OpenMeetings Version 3.1.2
> * OS: unix freebst 10.2
> * OpenMeetings high performance script ausgeführt -> Details siehe
> http://openmeetings.apache.org/JVMPerformanceTuning.html
> * RAM: 8GB
> * virtualisiert -> VMWare - ESXI 6.0
>
> 1.0)
> What would you recommend in detail (OS/setup/configuration/etc.) to do if
> you had to setup a system with following requirements to the
> OpenMeetings-system? :
> * maximum user in different sessions: 50
> * maximum users in the system: several thousand
> * maximum users logged in in simultaneous sessions: several thousand
> * webcam-video streaming has to be enabled for the sessions
> * location: worldwide access from users
> * maximum duration of a single OM-session: up to three hours
> * maximum download-size of single file during openmeetings-sessions: 50MB
> Are there any constraints in the system for fulfilling these requirements?
> (one or more requirement parameters) - if yes, which ones in detail and why?
> What factors are the bottlenecks in the requirements above?
> Is clustering recommended or even a mandatory-setup-part to fulfill these
> requirements? - if yes, how in detail would you recommend to realize it for
> fulfilling the requirements?
> What problems could we face even with the best setup for fulfilling these
> requirements? (any known things / hints?)
> What would you recommend (OS/setup/configuration) for the best-known
> om-setup in your internal development-tests - how in detail did you achieve
> best performance with your systems?
>
> 2.0)
> Are there any known bugs with following browsers?
> * Firefox
> * Safari
> ?
> We faced the fact that users are thrown out of sessions,
> especially if a user changes webcam-solution or audio-settings.
>
> With following Browsers there is a better, nearly stable behaviour in our
> tests:
> * Chrome
> * Internet Explorer
> 3.0)
> We have still the problem that user-session-contexts cannot be deleted out
> of
> Administration -> Connections. If we click a user-session to logout and OK
> the messagebox
> the user does not disappear out of the list. - so we cannot delete sessions
> manually and it seems
> that our system conserves any user-session of all logged in users - even
> multiple times, what seems to be a big error for me. Hopefully a restart of
> the om-system cleans all users out of their session-contexts. Could this be
> the source of our problems in our test-runs using OpenMeetings?
> Could this problem be solved somehow? (any ideas?)
>
> 4.0)
> Are any constraints possible via OpenMeetings-Configuration?
> Is it possible to limit simultaneously available rooms?
> Is it possible to limit simultaneously available users?
>
> Thank you very much,
> any help and hints are highly appreciated.
--
WBR
Maxim aka solomax
