On those occasions when a Meeting invitation may attract more participants than expected or planned for at the last minute so that you are unable to increase Seminar capacity in a timely manner, a skilled host can use two or more Connect Meeting rooms and project them to participants as though it were one room as an emergency workaround. Here is a basic outline of how to split a large meeting onto multiple servers. It is prudent to not just have more than one Meeting in these cases, but also to make sure each Meeting is hosted on a separate server in a cluster to add robustness to the meeting. Load-balancing is a wonderful thing and you should always use it to its fullest.
Assume an example of a three-server cluster/pool of Connect servers and that you want to split a Connect Meeting onto all three servers; a simple 3-server cluster is depicted here to use as an example:
For a working example, let’s place a Connect Meeting room hosted on each server; to do this you will need three separate URLs: One URL for each 1/3rd of your attendees. Getting the attendees distributed among the three rooms can be tricky. One effective technique is to either send out three different invitations, with each targeting 1/3rd of your audience and each offering a different URL, or just point everyone to a page with all three URLs and request/instruct the participants to alphabetically arrange themselves in subsets of users by URL selection. That way it is not random; I have seen this technique work fine; here are sample meeting URLs based on our picture above:
To make certain the each meeting is hosted on a separate server (rather than all three on one as load-balancing could easily prescribe), it will either require some effort to keep entering and leaving the room until your meeting lands on the server you want.
The way to tell which server you are on is simple: In any meeting room click Help and while holding down the shift key click About Adobe Connect. This will pop up an RTMP string that will identify the server that Meeting is hosted on and also which server a client is coming through as each client can be using multiple servers (just to add not only to the complexity, but also the overall robustness).
Here is what the RTMP strings might look like for each of the three servers in our simple example above ( I am inserting some URL parameters from a hosted meeting as I write this in order to create our hypothetical example RTMP strings – rtmp://arfms3.adobeconnect.com:1935/?rtmp://pcparapp07:8506/meetingas3app/89676385/630888204/)
The first name in the string (connectmtg0#) is the built-in Connect Edge server and the second name (connapp0#) is the Connect origin server hosting the meeting (each Connect servers runs both AMS/FMS and Tomcat together). The second name is the important one for our technique of splitting the attendees onto separate meeting servers.
In the hypothetical RTMP string samples above, I have made these artificially neat and tidy, the truth is that the first part of the string can be any of the three for any meeting participant regardless of the application server hosting the meeting. For example, you could come in to connapp01 through connectmtg03 – any combination is possible. Load balancing is done at more than one level as Connect leverages both a hardware-based load-balancing device and also its own internal clustering capabilities; combinations for various clients (including the hosts and presenters) in our example cluster depicted above might include:
The key to remember is that the second name is the one that matters; a distribution of participants approximating 1/3rd on each server is the goal targeting: connapp01, connapp02 and connapp03. After this is set-up, the pre-meeting preparation part is complete (this should be done at least one hour prior to the meeting).
Next comes the creative hosting venture during the split meeting: As the host, you will need all three meetings open in front of you to manage them as one. From the perspective of the participants, there is only one meeting (ignore the host behind the curtain). Be sure to hide the Attendee List Pod in the Presenter-only area as it will only present those participants in that specific Connect Meeting thereby allowing a peek behind the curtain or misrepresenting the size of the entire three meeting combination.
And here is where the techniques are very much up to you:
- Splitting video among the three rooms is possible using a third-party option, one we have used successfully is: Splitcam.com.
- For audio, if using integrated audio, be sure to use the same integrated telephony number for all three rooms.
- If using VoIP, then allow one speaker only at a time to send audio via VoIP.
Some ways in which you can limit the amount of data being processed in your room and to improve the overall performance of these sessions are:
- Optimize room bandwidth to DSL, regardless of your setting. In a Connect Meeting, at the top of the screen click on MEETING > Room Performance and Appearance > Optimize Room Bandwidth > DSL
- Turn off cameras whenever they are not in use.
- When in use, multiple cameras should probably be set to SLOW images (depending on how many and other variables).
- Turn off VoIP if not talking.
- Participants should directly connect to the fastest internet connection available and be on a dedicated DSL connection, at a minimum.
- No clients or hosts on wireless – allow no exceptions.
- Shut down Email, instant messaging, and any programs NOT being used for the presentation.
- Shut down any VPNs as a VPN will potentially destroy the possibility for success.
When large Connect Meetings or Seminars become commonplace in your enterprise, this cumbersome workaround quickly becomes impractical and you should increase your Seminar or Webinar licensed capacity as needed to avoid this complexity and manual work. With that said however, this technique will work in a bind and will provide a robust Connect Meeting experience for a very large audience even if it challenges a seasoned Connect Meeting host.