iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
MessagePack can reduce SignalR message size, but that alone does not guarantee lower end-to-end latency. To diagnose slow results in a k6 test, first verify that the test is exercising SignalR with the intended protocol and transport; then check the load generator, server, workload, and scale-out setup. “1,000 users” is not a reproducible target until you define how many connections are open and how actively they send messages.
What MessagePack can—and cannot—fix
ASP.NET Core SignalR supports JSON, its default hub protocol, and MessagePack, a binary protocol. Microsoft says MessagePack generally creates smaller messages. That is a payload-size benefit, not a guarantee of faster invocation round trips: latency also depends on transport, application work, network conditions, message frequency, fan-out, and system capacity. See Microsoft’s MessagePack protocol documentation and the SignalR overview.
The server can register MessagePack support while retaining JSON support; the client selects the protocol. Therefore, a configuration change is not proof that both sides are using MessagePack. Confirm the negotiated or configured protocol in the actual test before comparing results.
Recommended Free Tools
First confirm the test is exercising SignalR correctly
Check the transport
SignalR can use WebSockets, Server-Sent Events, or Long Polling. Microsoft identifies WebSockets as the preferred transport because it generally offers the best performance, but the selected transport can depend on client and server capabilities and configuration. Record or otherwise verify the transport for every run. A JSON-versus-MessagePack comparison is not controlled if one run uses WebSockets and the other falls back to a different transport.
Check the hub protocol and message exchange
k6 documents generic WebSocket support, but the cited documentation does not establish a built-in client that emulates the SignalR Hub Protocol with MessagePack. A raw WebSocket connection or echo test is not equivalent to a SignalR hub workload. The test client must perform the required SignalR handshake and framing and send and receive messages using the protocol under test. Validate a real request-and-reply or other representative hub operation before measuring performance. See k6’s WebSockets documentation and WebSocket API reference.
Define what “1,000 users” means
These workloads impose different demands, so state which one your test represents:
- 1,000 concurrent connections: 1,000 clients stay connected, but some may send few or no application messages.
- 1,000 active producers: all 1,000 clients send messages at the specified rate, creating substantially more processing and network work.
- A population of 1,000 users: only a fraction may be connected or active at a given time.
Also specify connection ramp-up, test duration, message-size distribution, messages per client, think time, group membership, and whether each message is sent to one client or fanned out to a group. Without those details, a connection count alone cannot establish expected latency or capacity.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Measure invocation latency, not just WebSocket activity
k6 provides WebSocket metrics such as connection duration, sent and received message counts, ping duration, and session duration. Those are useful for diagnosing the socket session, but they do not by themselves report application-level SignalR invocation round-trip latency. Instrument a timestamped request/reply or another meaningful hub operation and record elapsed time in a custom k6 Trend. Report at least p50, p90, p95, and p99 alongside errors and reconnects. The k6 metrics reference describes the built-in metrics.
Separate connection establishment from steady-state message latency. A slow ramp or handshake can make a test look unhealthy even when established connections handle messages normally; conversely, a healthy connection phase does not rule out slow application operations under sustained load.
Use a controlled JSON-versus-MessagePack comparison
Change only the protocol between runs. Hold the following conditions constant, and record the observed values rather than assuming they are equivalent:
- Application build, .NET runtime, client implementation, and server configuration.
- Transport, connection count and ramp, session duration, and reconnect behavior.
- Message payload distribution, message rate, think time, hub methods, and group fan-out.
- Deployment topology, server resources, downstream dependencies, and k6 generator resources.
For each run, report message bytes, successful connections, errors and reconnects, custom invocation round-trip latency percentiles, server CPU and memory, and generator CPU, memory, and network use. Repeat runs and report their variance. A smaller payload with unchanged or worse latency may mean serialization was not the limiting factor, or that another bottleneck dominates; it does not establish that MessagePack itself caused the result.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesDiagnose high latency in this order
- Verify protocol and transport. Confirm the client and server use the intended hub protocol and that the transport remains the same across test runs.
- Validate SignalR behavior in the load client. Confirm the handshake, framing, MessagePack encoding where applicable, and a meaningful request/reply work before increasing load.
- Separate connection and message phases. Measure connection establishment independently from steady-state hub-operation latency.
- Check the generator. Monitor k6 CPU, memory, network, open file descriptors, and dropped iterations. Grafana notes that operating-system file-descriptor limits can prevent tests with hundreds or thousands of concurrent VUs from opening the required connections. If one machine cannot sustain the intended workload, use distributed generation. See k6’s operating-system tuning guidance.
- Check the server and dependencies. Observe CPU, memory, runtime and thread-pool behavior, network, and downstream services while latency rises. Correlate those signals with the time series for invocation latency and errors.
- Inspect payloads and fan-out. Compare actual bytes sent and received, message frequency, and how many recipients each hub operation reaches. Smaller serialization output does not remove the work of processing or delivering messages.
- Review deployment and scale-out. SignalR connections are persistent and consume TCP connection capacity and memory. For multi-server deployments, examine connection distribution and session affinity, along with the backplane or managed-service topology and available socket capacity. Microsoft’s hosting and scaling guidance is indexed for ASP.NET Core 6.0, so verify the relevant details for your runtime and hosting platform. The article notes exceptions to affinity requirements, including Azure SignalR Service and WebSockets-only clients configured to skip negotiation.
- Compare serialization last. Once the client, transport, generator, workload, and deployment are controlled, compare JSON and MessagePack message sizes and invocation-latency percentiles across repeated runs.
Ramp load without confusing connection pressure with steady-state performance
Use staged ramps to find where connection success, errors, or latency begin to change, then hold a steady period long enough to observe sustained behavior before cooling down. Include realistic message rates and think time instead of having every virtual user send continuously unless that is the intended workload. Set thresholds from your product’s service-level objective; example HTTP thresholds in k6 guidance are illustrative and are not SignalR targets. Grafana’s performance-testing example demonstrates staged load and thresholds.
Do not treat timeout settings as a latency tuning shortcut
Current ASP.NET Core 10 SignalR configuration documentation lists defaults of 15 seconds for HandshakeTimeout, 15 seconds for KeepAliveInterval, and 30 seconds for ClientTimeoutInterval. The handshake timeout applies when a client does not send its initial handshake within the interval; the documentation recommends coordinating client and server timeout settings with keep-alive settings. These are connection-management settings, not direct fixes for slow application message handling. Change them only to address a diagnosed connection or timeout problem, using the SignalR configuration documentation for the target runtime.
What a 1,000-user result can support
A valid result describes the tested application, runtime, transport, topology, generator, connection behavior, and message workload. It can show how that specific setup behaved at the measured load, and whether MessagePack reduced the observed message size or changed measured latency. The cited Microsoft and k6 documentation does not establish a universal latency improvement, capacity limit, or expected result for 1,000 SignalR users. Do not turn one workload’s result into a general capacity promise.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
