On this page
Every Jitsi capacity number you read online, including ours, was measured on someone else's servers, bandwidth and meeting pattern. The only number that matters for your launch is the one from your own deployment. A load test gets you that number before real users find it for you.
Jitsi ships its own tool for this. It lives in jitsi-meet-torture, which is still actively maintained, and the load test inside it is called Malleus. This guide replaces our 2020 walkthrough, which used a Selenium 3 Docker image we published at the time. That image has not been updated since 2020, so use the current setup below instead.
What a Jitsi Meet test under load tells you
Jitsi fails in a predictable order as load grows, and a good test is designed to find the first failure:
| Component | What runs out | Symptom |
|---|---|---|
| Videobridge | CPU and outbound bandwidth | Frozen video, dropped resolution, audio gaps |
| Prosody and Jicofo | Signaling capacity per shard | Slow joins, participants stuck connecting |
| Clients | Browser CPU decoding many streams | Laggy UI for participants on weak laptops |
The videobridge is almost always first. Which is why the shape of the test matters so much: 100 participants with 2 people sending video is a completely different load from 100 participants with 20 cameras on. If the components in that table are unfamiliar, the Jitsi architecture overview explains what each one does.
How Malleus in Jitsi Meet Torture works
Malleus is a test in the torture suite, started through scripts/malleus.sh. It connects to a Selenium Grid, asks for one browser session per participant, and has each session join a room on your Jitsi server with fake camera and microphone input. Participants stay for the duration you set, then leave.
The Selenium Grid does the heavy lifting. The machine running malleus.sh only coordinates; the browsers run on grid nodes, and you add nodes until they can hold the number of participants you want to simulate.
Build a Selenium Grid
The torture repository includes a grid setup for Selenium 4 in doc/grid. It builds browser images with a sample video and audio file baked in, so every simulated participant sends realistic media. On a machine with Docker:
git clone https://github.com/jitsi/jitsi-meet-torture.git
cd jitsi-meet-torture/doc/grid
cp -r ../../resources .
wget -P resources https://github.com/jitsi/jitsi-meet-torture/releases/download/example-video-source/FourPeople_1280x720_30.y4m
docker build --build-arg VERSION=latest --build-arg BROWSER=chrome -t jitsi/standalone-chrome:latest .Then start the dynamic grid from the compose file in the same folder:
docker compose -f docker-compose-v3-dynamic-grid.yml up -dA dynamic grid starts a fresh browser container for every session and removes it afterwards, so participants don't leak state between runs. The grid dashboard is at http://grid-host:4444/. One machine only holds as many browsers as its CPU allows; for bigger tests, add node machines to the same grid as described in the docker-selenium documentation.
Keep the grid off your Jitsi servers
Run a Jitsi test with malleus.sh
Point it at a server you control, such as one built from our Ubuntu install guide. On the controller machine you need a JDK and Maven, since malleus.sh runs the test through mvn. From the root of the repository:
./scripts/malleus.sh \
--conferences=2 \
--participants=20 \
--senders=4 \
--audio-senders=4 \
--duration=300 \
--room-name-prefix=loadtest \
--hub-url=http://grid-host:4444/wd/hub \
--instance-url=https://meet.example.com \
--headlessThat runs two conferences of 20 participants each, where 4 per room send video and audio and the rest only receive, for five minutes. The parameters that change the load most:
--participantsand--conferencesset the total. Total browser sessions is the product of the two.--sendersis the number of participants per room sending video. This drives bridge CPU far more than the participant count does.--audio-senderscontrols unmuted microphones separately.--durationin seconds. Short runs hide problems that only appear once bridges warm up, so do at least one long run.--use-load-testand--use-lite-modeswitch to lighter client modes, and--senders-per-tabpacks more participants into each browser tab. Use them when the grid, rather than Jitsi, runs out of capacity first.
Always pass --instance-url. The script's older positional form defaults to meet.jit.si, a public service you must not load test.
What to measure
Increase load in steps: 25, 50, 100 participants, same sender count, and record at each step.
- Videobridge CPU and outbound bitrate. Watch the bridge, not just the host average. The bridge's own stress level comes from its colibri statistics, and Jicofo uses it to decide when a bridge is full.
- Jicofo's view. Participant and conference counts should match what Malleus started. A gap means joins are failing.
- The grid nodes' CPU. If a node sits near 100%, the browsers are the bottleneck and your numbers describe the test rig, not Jitsi.
- A real human in the room. Join one of the test conferences from a normal laptop. Numbers can look fine while the experience is already bad.
For context on what one well-sized bridge and shard can hold, our 1000-user Jitsi test shows how the limits behaved on real hardware, and the 2022 test with 235 concurrent users shows a smaller setup under the same kind of load. When your test finds the ceiling of one bridge, load balancing multiple videobridges is the next step, and auto scaling Jitsi Meet on AWS covers growing and shrinking that pool automatically.
Mistakes that ruin the numbers
- Every participant sending video. Real meetings have a few speakers. A test with 100 cameras on measures a meeting nobody holds.
- No fake media. Browsers without a video file send black frames or nothing, and the bridge barely works.
- Testing only one conference. Many medium meetings stress Jicofo and bridge selection differently from one huge meeting. Test the pattern you expect.
- Forgetting the last-n setting. If your
config.jslimits how many video streams each client receives, test with the same setting, or the bridge does very different work.
Frequently Asked Questions
What is Jitsi Meet Torture?
jitsi-meet-torture is Jitsi's own browser-based test suite. It drives real Chrome or Firefox sessions through Selenium to join meetings, and it includes Malleus, the test used for load: it opens many participants across many conferences and keeps them in the call for a set duration.
How do I make a Jitsi test call?
Open your server's URL in two browsers or devices and join the same room, then add a third to bring the videobridge in. For a connection check before joining, enable preCallTestEnabled in prejoinConfig. For hundreds of test participants at once, use Malleus.
Can I load test Jitsi Meet without Selenium?
Not realistically for media load. The videobridge's cost comes from real audio and video streams, so you need clients that actually encode and send media. Synthetic XMPP-only tools can test signaling, but they tell you nothing about bridge CPU and bandwidth.
How many participants can one Selenium node simulate?
It depends on the machine and on how many participants send video. A full Chrome session that sends video is expensive, while receive-only participants are much cheaper. Start with a small node, watch its CPU during a run, and scale the grid before the node itself becomes the bottleneck.
What should I monitor during a Jitsi load test?
Videobridge CPU and outbound bandwidth first, since they hit limits before anything else. Then the bridge's stress level from its colibri stats, Jicofo's participant and conference counts, and the grid nodes' CPU so you know the test clients were not the bottleneck.
Is it safe to load test meet.jit.si?
No. Malleus defaults to meet.jit.si when called with the old positional arguments, which is a public service run by 8x8. Always pass --instance-url with your own server, and never point load tests at infrastructure you do not own.
Need Jitsi Capacity You Can Trust?
We size, load test and scale Jitsi Meet deployments for real meeting patterns, from a single shard to multi-region setups.
Talk to Meetrix About Jitsi Support
