https://livekit.io logo
Join Slack
Powered by
How can I perform a load test on my agent?
# ask-ai
b
How can I perform a load test on my agent?
t
Thanks for reaching out, Harsh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
If you want to put your agent through its paces with a load test, you can use the 
lk perf agent-load-test
command. Here’s a friendly guide to help you get started: Before You Begin: • Make sure your agent is up and running, and that it has an 
agent_name
set. • Start your agent with 
lk start
rather than 
lk dev
for the test to work smoothly. How to Run the Test: 1. Simply run this command to kick off the load test:
Copy code
lk perf agent-load-test \
  --rooms 5 \
  --agent-name test-agent \
  --echo-speech-delay 10s \
  --duration 5m
Breaking Down the Command: • `--rooms`: How many rooms you want to open (like 5 rooms). • `--agent-name`: The name of your running agent that will join those rooms (for example, "test-agent"). • `--echo-speech-delay`: The pause between when the echo track speaks and when your agent responds (say, 10 seconds). • `--duration`: How long you want the test to run (like 5 minutes). What’s Happening During the Test: • The test spins up multiple rooms and sends your chosen agent into each one. • Each room gets an echo participant that mimics user interaction by echoing back the agent’s audio after the delay you set. Checking Out the Results: When the test wraps up, you’ll see a neat table with stats for each room, including: • How quickly the agent was dispatched and joined • Whether the tracks were subscribed to successfully • Whether the echo tracks published correctly If you want to dive deeper, feel free to check out the LiveKit documentation on load testing. It’s got all the details you might need. Sources: autocomplete/fish_autocomplete
b
there's no perf command available
t
Hey there! If you can’t find the 
lk perf
command, no worries—here are some easy steps to help you get it sorted: 1. Check your LiveKit CLI version: Make sure you’re running the latest version. You can install or update it with these commands depending on your OS: ◦ For macOS: 
brew install livekit-cli
◦ For Linux: 
curl -sSL <https://get.livekit.io/cli> | bash
◦ For Windows: 
winget install LiveKit.LiveKitCLI
1. Verify available commands: Try running 
lk --help
to see if 
perf
shows up. If not, keep going with the next steps. 2. Check for subcommands: Run 
lk perf --help
to see if any performance testing commands are tucked away under subcommands. 3. Reinstall the CLI: If you still don’t see it, try uninstalling and reinstalling the LiveKit CLI to make sure everything’s installed properly. 4. Look for alternative commands: Sometimes, performance testing features might be found under other commands like 
lk load-test --help
. If you’re still stuck after trying these, just give me a shout—I’m here to help! Sources: autocomplete/fish_autocomplete | CLI Setup | LiveKit Docs | CLI Setup | LiveKit Docs | Agents Core Architecture | livekit/livekit_composite | DeepWiki | LiveKit CLI | livekit/livekit_composite | DeepWiki
b
I have lk load-test command
t
Hey there! You can use the 
lk load-test
command to run load testing in LiveKit. Here’s a simple way to get started: Basic Usage: • Simulate video publishers: 
lk load-test --room test-room --video-publishers 8
This will simulate 8 video publishers with simulcast enabled at 720p, 360p, and 180p. • Simulate audio publishers: 
lk load-test --room test-room --audio-publishers 5
This one simulates 5 audio publishers. • Simulate subscribers: 
lk load-test --room test-room --subscribers 500
Here, you simulate 500 subscribers. Customizing the Load Test: • For a large meeting scenario: 
lk load-test --room test-room --video-publishers 150 --subscribers 150
• For a livestreaming scenario: 
lk load-test --room test-room --video-publishers 1 --subscribers 3000
• Want to set video resolution? 
lk load-test --room test-room --video-publishers 10 --video-resolution medium
• To disable simulcast: 
lk load-test --room test-room --video-publishers 5 --no-simulcast
• To simulate a grid layout: 
lk load-test --room test-room --video-publishers 10 --layout grid
Advanced Tips: • It’s a good idea to run the load tester from a cloud instance to avoid any bandwidth hiccups. • Make sure your system settings are set up right:
Copy code
ulimit -n 65535
sysctl -w fs.file-max=2097152
sysctl -w net.core.somaxconn=65535
Monitoring the Test: You can generate a token and join the room to watch how the test is going:
Copy code
lk token create --join --room test-room --identity test-user --open meet
If you have any questions or need a hand with anything else, just let me know!
b
I want to test how many simultaneous calls I can do
t
If you want to see how many simultaneous calls your setup can handle, you can try out the 
lk load-test
command. Here’s a simple way to get started: Steps: 1. Run this command to simulate multiple calls at once:
Copy code
lk load-test \
  --url <your-server-url> \
  --api-key <your-key> \
  --api-secret <your-secret> \
  --room load-test \
  --video-publishers 150 \
  --subscribers 150
Just swap out 
<your-server-url>
, 
<your-key>
, and 
<your-secret>
with your LiveKit server info. Key Parameters to Know: • `--video-publishers`: How many participants are sending video. • `--subscribers`: How many participants are receiving video. • `--duration`: How long you want the test to run (for example, 
--duration 5m
for 5 minutes). • `--video-resolution`: Choose the video quality (like high, medium, or low). • `--no-simulcast`: Turn off simulcast if that fits your needs. Some handy tips: • It’s best to run the load test from a cloud VM so your local bandwidth doesn’t get in the way. • Make sure your system settings are optimized for performance with these commands:
Copy code
ulimit -n 65535
sysctl -w fs.file-max=2097152
sysctl -w net.core.somaxconn=65535
After running the test, you’ll get stats like bitrate, packet loss, and latency to help you understand how things are performing. If you have any questions or want a hand with anything else, just let me know—I’m here to help!
b
I want agent to join different rooms
t
Hey there! If you want to set up an agent to join multiple rooms during load testing, you can use the agent load testing utility. Here’s a simple way to get it going: Steps: 1. Just run this command to kick off the test:
Copy code
lk perf agent-load-test \
  --rooms 5 \
  --agent-name test-agent \
  --echo-speech-delay 10s \
  --duration 5m
What each part means: • `--rooms`: How many rooms you want the agent to join (like 5 rooms here). • `--agent-name`: The name of your agent that will join the rooms (for example, "test-agent"). • `--echo-speech-delay`: How long to wait between the echo track speaking and the agent responding (here, 10 seconds). • `--duration`: How long you want the test to run (say, 5 minutes). Here’s what happens: • The test sets up multiple rooms and sends your agent into each one. • Each room gets an echo participant that mimics user interaction by repeating what the agent says, after a little delay. Just make sure your agent is up and running with the 
agent_name
you specified. If you hit any bumps or want to chat more about it, I’m here to help! Sources: pkg/loadtester/loadtester.go
b
I am getting this error - Failed to connect to room room-0-4iKqdM92mDar: could not dial signal connection
t
The error 
Failed to connect to room: could not dial signal connection
usually means there’s a hiccup in establishing a WebSocket connection with the signaling server. Don’t worry—here are some friendly steps to help you troubleshoot and get things back on track: 1. Check Network Connectivity: • Make sure your internet connection is steady and working well. • Double-check that WebSocket ports (443 for 
wss
or 80 for 
ws
) aren’t being blocked by firewalls or VPNs. • Try testing the connection to the LiveKit server using tools like 
curl
or your browser’s developer tools. 2. Validate the Server URL: • Confirm the WebSocket URL is correct and formatted properly. • Use 
wss://
if you want a secure connection, or 
ws://
for non-secure. • Check that the URL includes the right path (like 
/rtc
for signaling). 3. Verify Authentication Tokens: • Make sure your token is valid and hasn’t expired. • Also, verify the token has the right permissions to connect to the signaling server. 4. Check Server Availability: • Ensure the signaling server is up and running. • You can use tools like 
ping
or 
curl
to see if the server is responsive. 5. Enable Logging: • Turn on detailed logging on both the client and server to catch more info about the error. • Take a look at the WebSocket connection handshake and any error messages the server sends back. If you want a hand with any of these steps or have more questions, just let me know—I’m here to help! Sources: signalling/signaltransport_websocket.go | src/api/SignalClient.ts
b
I am getting this error now - dropping candidate with ufrag GKHbItuIwTcXMXHT because it doesn't match the current ufrags
t
That error 
dropping candidate with ufrag because it doesn't match the current ufrags
usually pops up when there’s a mismatch in the ICE username fragment (ufrag) during the ICE Trickle process. Don’t worry, here’s a friendly guide to help you sort it out: 1. Make Sure ICE Credentials Are Consistent: • Double-check that the 
ufrag
and 
pwd
values stay the same across all your SDP messages, including offers, answers, and any later fragments. 2. Take a Look at Your SDP Parsing: • Go over your SDP parsing logic to confirm you’re correctly pulling out and setting the 
ufrag
and 
pwd
values. • Try using LiveKit’s helper functions—they’re super helpful for handling ICE credentials the right way. 3. Get Trickle ICE Right: • Follow the Trickle ICE spec (RFC 8840) to manage how candidates are exchanged bit by bit, making sure both sides stay in sync. 4. Log and Debug Thoughtfully: • Check your server logs for more clues about what’s going on. • Trace the SDP fragments and credential checks using LiveKit’s transport layer logging—it can shed light on tricky issues. 5. Manage State Carefully: • Keep an eye on state management when handling ICE candidates, especially after ICE restarts or renegotiations, to avoid mismatches. If you want, I’m here to help you dig deeper—just share any details you have, and we’ll figure it out together!
b
I am getting this error 2025-08-15T181721.417-0500 ERROR lk v2@v2.9.3-0.20250809171724-6ac93dd428bf/room.go:332 failed to join room {"retrying in": "2s", "url": "some url", "error": "could not connect after timeout"} github.com/livekit/server-sdk-go/v2.(*Room).JoinWithToken github.com/livekit/server-sdk-go/v2@v2.9.3-0.20250809171724-6ac93dd428bf/room.go:332 github.com/livekit/server-sdk-go/v2.(*Room).Join github.com/livekit/server-sdk-go/v2@v2.9.3-0.20250809171724-6ac93dd428bf/room.go:292 github.com/livekit/livekit-cli/v2/pkg/loadtester.(*LoadTestRoom).start github.com/livekit/livekit-cli/v2/pkg/loadtester/agentloadtester.go:174 github.com/livekit/livekit-cli/v2/pkg/loadtester.(*AgentLoadTester).Start.func1 github.com/livekit/livekit-cli/v2/pkg/loadtester/agentloadtester.go:92 golang.org/x/sync/errgroup.(*Group).Go.func1 golang.org/x/sync@v0.16.0/errgroup/errgroup.go:93
t
Hey there! That 
failed to join room: could not connect after timeout
error pops up when your client can’t connect to the LiveKit server within the time it’s allowed. No worries though, here are some friendly steps to help you fix it: 1. Increase the Connection Timeout: • Try giving your client a bit more time to connect by adjusting the timeout settings. For example, in JavaScript:
Copy code
const options = {
  websocketTimeout: 10000, // 10 seconds
  // Other options...
};
2. Check Network Conditions: • Make sure there aren’t any network hiccups or firewall blocks getting in the way. • Double-check that the LiveKit server URL is reachable from your end. 3. Verify LiveKit Server URL: • It’s always good to confirm the server URL is correct and actually points to your LiveKit setup. 4. Enable Retry Logic: • Adding retries with exponential backoff can help handle temporary connection glitches. Here’s how you might do it in Go:
Copy code
for tries := uint(0); !isSuccess; tries++ {
    callCtx, cancelCallCtx := context.WithTimeout(ctx, 4*time.Second)
    isSuccess, err = r.engine.JoinContext(callCtx, bestURL, token, params)
    cancelCallCtx()

    if err != nil {
        d := time.Duration(1 << min(tries, 6)) * time.Second // max 64 seconds
        time.Sleep(d)
        continue
    }
}
5. Check Server-Side Logs: • Take a peek at the server logs to see if anything there might give clues about what’s going wrong. 6. Use Regional URLs: • Connecting through regional URLs can really help improve connection quality and avoid regional server hiccups. If you want, I’m here to help you walk through any of these steps—just let me know! Sources: room.go | LiveKit Server Components | livekit/livekit_composite | DeepWiki | src/api/SignalClient.ts | Shared/Contexts/RoomContext.swift
2 Views
Open in Slack
PreviousNext
Powered by