虛擬活動都是獨一無二，對用户容納數量有着不同的需求。在這篇博文中，Mozilla討論了將併發性視為虛擬活動一部分的不同方法，Mozilla Hubs和Hubs Cloud用於支持用户的當前功能，以及將Hubs用於不同規模活動的注意事項。如果你有考慮在會議中使用Hubs，或者只是單純對平台的工作方式感興趣，你可以繼續閲讀本文。
1. 虛擬活動的併發籌劃
當我們進行傳統的活動規劃時，我們都需要考慮一個重要的限制：可用空間的物理量。當我們將線下活動搬到線上，並因而消除了這一考量後，我們很難理解給定平台可能存在的限制。
利用在線協作軟件，一系列的因素將發揮作用。應用程序可能存在基於活動的限制，基於房間的限制或基於平台的限制，並可能會影響用户容量的規劃執行。Hubs存在“基於房間”和“基於平台”的用户限制，而所述限制取決於你是不是在hubs.mozilla.com創建房間，或者是否使用Hubs Cloud。在規劃參與活動的人數時，重要的是要考慮用户的分佈和活動內容。這與實際的活動規劃相關：儘管一個場館可以容納數千人，但你同時需要考慮不同的房間可以容納多少人。
在思考如何使用Hubs或Hubs Cloud舉行活動時，你可以考慮兩種不同的選項：一種是從你要支持的人數開始，然後將用户分到多個房間；另一種是從活動規模開始，然後計算出需要多少個房間。下面我們將介紹有關Hubs和Hubs Cloud的空間與系統功能考量。
2. Hubs房間容量
對於Hubs，問題變得更為複雜，因為你可以通過集Hubs Cloud控制房間容量和“場館”容量。Hubs支持單個房間中最多容納50名用户。但需要注意的是，這是服務器對單個房間可容納人數的限制，不能保證每個人都能獲得適宜的體驗。一般來説，通過智能手機或VR一體機接入的用户會先於使用遊戲PC和有線網絡的用户看到性能下降。儘管Hubs在共享來自web的各種內容方面提供了居大的靈活性，但要支持分享大型文件或流式傳輸內容，用户生成內容通常會帶來大量的負載。所述性能問題通常表現為音頻體驗減損或幀率下降。
對於虛擬活動，與會者所採用的接入設備十分重要，家庭網絡配置同樣會產生影響。影響Hubs性能的因素包括：
在一個房間裏的人數房間中的內容量房間中的內容類型
所以，Mozilla將默認房間容量設置為服務器總容量的一半左右，因為用户可能進入一個包含50名虛擬化身的房間。服務器容量存在上限，因為每位接入房間的用户都會打開一個服務器通道併發送網絡數據，而且當用户數較高時，服務器運行的軟件必須付出大量的努力才能處理相關數據，並將其實時發回其他客户端。儘管增加可用服務器的大小和數量有助於系統範圍內的併發性，但考慮到接入客户端之間的底層會話描述協議協商是一個單線程進程，所以單個房間容量不會增加超過50個以上。
Room Lobby頁面顯示了會議室中人員和對象的列表，並允許用户在進入之前查看和聽到正在發生的一切。
Hubs同時具有房間“大廳”的概念。在這裏，訪客可以看到房間裏發生的一切，聽到正在討論的內容，並通過聊天發送信息，但他們並不以虛擬化身的形式出現。儘管Hubs中的大廳系統最初是設計成為在用户進入房間之前提供相關的情景信息，但現在大廳可以用作大型活動的輕量級預覽體驗，類似於你在Twitch等二維流式媒體平台中所經歷的情況。Mozilla最近進行了一個實驗性的改動，測試了多達90名客户在大廳查看共有10人的房間。對於適合被動式瀏覽體驗的活動，這種方法可以容納比房間更多的人數，因為大廳用户不向服務器發送數據，只接收數據，這對房間負荷的影響較小。
3. 擴展Hubs Cloud
儘管空間限制是虛擬活動的一個考慮因素，但系統範圍的併發性成為了另一個問題。與實體場館一樣，虛擬平台同樣對支持用户總數設置上限。這通常是應用程序後端運行的服務器功能和硬件的結果。對於Hubs Cloud，這主要取決於EC2服務器的大小，以及你是使用單個服務器還是多個服務器。一個小型的t3.micro服務器能夠處理比c5.24xlarge更小的同時用户負載。在計算用於Hubs Cloud部署的服務器實例大小時，這是需要考慮的一個重要因素。
對於在Hubs Cloud運行的大型活動，確切的配置將取決於將要運行的會話類型，每個Hubs房間中有多少用户，以及用户是作為大廳的觀眾成員還是要具現在空間之中。Mozilla最近發佈了一份指南，説明了部署在AWS的不同實例大小是如何轉化為併發用户總數。
4. 活動籌劃策略
要將Hubs整合到虛擬活動中，不同的活動有着不同的需求。對於每一個活動，我們建議你要掌握相關的管理工具和最佳實踐，但Mozilla根據實驗和反饋提供了針對不同會議和組織的配置與策略示例。
對於最多25人的組別：一般而言，一個hubs.mozilla.com中的房間已經足夠。如果所有用户都是通過智能手機或VR一體機接入的虛擬化身，你可以嘗試將羣組分成兩個或三個房間，並將它們鏈接在一起。
對於最多50人用户的組別：一個hubs.mozilla.com中的房間，其中演講者以虛擬化身出現，而大約一半的與會人士是從大廳瀏覽體驗，或兩個hubs.mozilla.com中的房間，其中一個房間用於小組發言，另一個房間是供觀眾使用
對於需要向50人以上用户廣播的活動：你可能需要設置一個允許你同時將視頻廣播到多個房間的流式傳輸服務，併為與會者提供一箇中心位置以便他們發現彼此。這可以是一個單獨的“大廳”房間，其中包含指向其他瀏覽區域的鏈接，或者是一個包含鏈接或嵌入不同房間的簡單網頁。儘管能夠在hubs.mozilla.com以這種方式主持活動，但在託管的Mozilla Hubs架構管理屬於同一活動的兩個以上房間可能很難協調和創建統一的體驗。對於需要兩個或三個以上房間的活動，我們建議部署Hubs Cloud實例。
在Hubs中觀看IEEE VR的主題演講
對於Hubs Cloud，你可以更為精細地控制房間和活動容量，因為你不是簡單地控制單個房間集的權限和設置，而是託管自己版本的hubs.mozilla.com。所以，你不僅可以設置平台範圍的權限和配置，同時可以添加自己的URL、品牌、帳户、虛擬化身和場景等等。
5. 未來的擴展，以及通過Hubs和Hubs Cloud實現的併發機制
不同小組配置Hubs的不同方式給我們留下了深刻地印象。Hubs最初是為具有封閉私人會議室的緊密鏡像平台設計，但隨着越來越多的人尋求能夠允許物理相隔的彼此能夠聯結交流的虛擬解決方案，Mozilla一直在尋找全新的方法來擴展平台，從而更好地支持更多的受眾。這意味着需要考慮數個重要問題：
要允許一大羣人虛擬地共聚一堂，什麼才是正確的設計呢？在考慮如何最好地支持更大的社區時，你需要考量特定的技術和社會方面。我們可以嘗試模擬物理環境的方法，只需專注於增加出現在同一個房間裏的虛擬化身的數量，或者可以進行更多的實驗，測試技術在重塑我們的社交和聚集方式時所呈現出的獨特可供性。對於虛擬會議平台所提供的功能，我們的假設存在什麼折衷之處，我們又將如何在規模更大的、可能不太可信的組別中保持隱私和安全原則呢？在我們的日常生活中，我們發現我們的行為深受周圍環境和社區的影響。當我們期待軟件解決方案來支持其中一些用例時，我們必須考慮這些安全和隱私結構是如何繼續成為平台的核心考量因素。
當然，關於web技術發展方式的潛在架構問題同樣存在，並影響着我們如何在平台增長時探索和響應用户社區。你可以通過Mozilla的社區Discord服務器，GitHub或電子郵件就這一領域進行討論、提出問題和作出貢獻。