Virtual events are unique, and each one has varying needs for how many users can be present. In this blog post, we’ll talk about the different ways that you can consider concurrency as part of a virtual event, the current capabilities of Mozilla Hubs and Hubs Cloud for supporting users, and considerations for using Hubs as part of events of varying sizes. If you’ve considered using Hubs for a meetup or conference, or are just generally interested in how the platform works, read on!
Concurrency Planning for Virtual Events
When we think about traditional event planning, we have one major restriction that guides us: the physical amount of space that is available to us. When we take away the physical location as a restriction for our event by moving our event online, it can be hard to understand what limits might exist for a given platform.
With online collaboration software, there are many factors that come into play. Applications might have a per-event limit, a per-room limit, or a per-platform limit that can influence how capacity planning is done. Hubs has both ‘per-room’ and ‘per-platform’ user limits. These limits are dependent on whether you are creating a room on hubs.mozilla.com, or using Hubs Cloud. When considering the number of people who you might want to have participate in your event, it’s important to think about the distribution of those users and the content of the event that you’re planning. This relates back to physical event planning: while your venue may have an overall capacity in the thousands, you will also need to consider how many people can fit in different rooms.
When thinking about how to use Hubs or Hubs Cloud for an event, you can consider two different options -- one where you start from how many people you want to support, and how they will be split across rooms, and one where you start from the total event size and figure out how many rooms will be necessary. Below, we cover some of the considerations for room and system-wide capabilities for Hubs and Hubs Cloud.
Hubs Room Capacity
With Hubs, the question gets a bit more complicated, because you can control the room capacity and the “venue” capacity via Hubs Cloud. Hubs supports up to 50 users in an individual room. However, it is important to note that this is the server limit on the number of people who can be accommodated in a single room - it does not guarantee that everyone will be able to have a good experience. Generally speaking, users who are connecting with a mobile phone or standalone virtual reality headset (for example, something with an Qualcomm 835 chipset) will start to see performance drops before users on a gaming PC with hardwired internet will. While Hubs offers a great amount of flexibility in sharing all sorts of content from around the web, user-generated content can often bring with it a large amount of overhead to support sharing large files or streaming content. Oftentimes, these performance issues manifest in a degraded audio experience or frame rate drops.
With virtual events, the device that your attendees are connecting from will make a difference, as will their home network configurations. Factors that impact performance in Hubs include:
- The number of people who are in a room
- The amount of content that is in a room
- The type of content that is in a room
As a result of these considerations, we set a default room capacity at about half of the total server capacity, because users will likely experience issues connecting to a room that has 50 avatars in it. The server limit is capped because each user that connects to a room opens up a channel to the server to send network data (specifically, voice data) and at higher number of users, the software running on the server has to do a lot of work to get that data processed and sent back out to the other clients in real-time. While increasing the size and number of servers that are available can help the system-wide concurrency, it will not increase individual room capacity beyond the 50 connection cap given that the underlying session description protocol (SDP) negotiations between the connected clients is a single-threaded process.
Hubs also has the concept of a room ‘lobby’. While in the lobby, visitors can see what is happening in the room, hear what is being discussed, and send messages via chat, but they are not represented as an avatar in the space. While the lobby system in Hubs was initially designed to provide context to a user before they were embodied in a room, it is now possible to use the lobby as a lighter-weight viewing experience for larger events similar to what you might experience on a 2D streaming platform, such as Twitch. We recently made an experimental change that tested up to 90 clients watching from the lobby, with 10 people in the room. For events where a passive viewing experience is contextually appropriate, this approach can facilitate a larger group than the room itself can, because the lobby viewers are not sending data to the server, only receiving it, which has a reduced impact on room load.
Scaling Hubs Cloud
While room limits are one consideration for virtual events, the system-wide concurrency then becomes another question. Like physical venues, virtual platforms will have a cap on the total number of connected users that it can support. This is generally the result of the server capabilities and hardware that the backend of the application is running on. For Hubs Cloud, this is primarily dependent on the EC2 server size that is running your deployment, and if you are using a single server or multiple servers. A small, t3.micro server (the smallest one that can run Hubs Cloud) will be able to handle a smaller simultaneous user load than a c5.24xlarge. This is an important consideration when figuring out how large of a server instance to use for a Hubs Cloud deployment.
The exact configuration for a large event running on Hubs Cloud will be dependent on the type of sessions that will be running, how many users will be in each Hubs room, and whether the users will participate as audience members from the lobby or be embodied in a space. We recently released an estimated breakdown of how different instance sizes on AWS deployments of Hubs Cloud translate to a total number of concurrent users (CCU).
Hubs Strategies for Events
Building out a strategy to incorporate Hubs into a virtual event that you’re holding will be unique to your individual event. With any event, we recommend that you familiarize yourself with the moderation tools and best practices, but we’ve offered a few sample configurations and strategies below based on what we’ve heard works well for different types of meetings and organizations.
For groups up to 25 users (e.g. small meetup or meeting, breakout sessions for a larger event) - a single room on hubs.mozilla.com will generally be sufficient. If all of your users are connecting via mobile phones or standalone headsets as avatars, you may want to experiment with splitting the groups across two or three rooms and linking them together.
For groups up to 50 users (e.g. a networking event and panel of speakers) - a single room on hubs.mozilla.com, where the speakers are represented as avatars and about half of the participants view from the lobby, or two rooms on hubs.mozilla.com, where one room is the panel room and one room is for viewers.
For events with speakers broadcasting to more than 50 users (e.g. conference keynote) - you will likely need to set up a streaming service that will allow you to broadcast video into several rooms simultaneously, with a central location made available for attendees to discover one another. This could be a separate “lobby” room with links to the other viewing areas, or a simple web page that has links or the different rooms embedded. While it is possible to host events this way on hubs.mozilla.com, managing more than two rooms as part of a single event on the hosted Mozilla Hubs infrastructure can be difficult to coordinate and create a unified experience. Instead, for events that require more than two or three rooms, we recommend deploying a Hubs Cloud instance.
With Hubs Cloud, you have more granular control over the rooms and availability of your event, because instead of simply controlling the permissions and settings of an individual set of rooms, you are hosting your own version of hubs.mozilla.com - so you not only can set platform-wide permissions and configurations, you also have the ability to add your own URL, branding, accounts, avatars, scenes, and more.
The Future of Scaling and Concurrency with Hubs and Hubs Cloud
We’ve been impressed with the different ways that groups have configured Hubs to meet, even with the existing infrastructure. Hubs was originally built to more closely mirror platforms that have closed, private meeting rooms, but as more people have looked to virtual solutions to stay connected during times of physical distance, we’ve been looking at new ways that we can scale the platform to better support larger audiences. This means considering a few big questions:
- What is the right design for gathering large groups of people virtually? In thinking about this question, there are technical and social considerations that come into play when considering how to best support larger communities. We can take the approach of trying to mimic our physical environment, and simply focus on increasing the raw number of avatars that can be present in a room, or we can take more experimental approaches to the unique affordances that technology presents in reshaping how we socialize and gather.
- What are the trade-offs in our assumptions about the capabilities offered by virtual meeting platforms, and how do we preserve principles of privacy and safety in larger, potentially less-trusted groups? In our day-to-day lives, we find our actions heavily influenced by the context and community around us. As we look to software solutions to enable some of these use cases, it is important for us to think about how these safety and privacy structures continue to be core considerations for the platform.
Of course, there are also the underlying architectural questions about the ways that web technologies are evolving, too, which also influences how we’re able to explore and respond to our community of users as the product grows. We welcome discussions, questions, and contributions as we explore this space in our community Discord server, on GitHub, or via email, and look forward to continuing to grow the platform in different ways to best support the needs of our users!