{"id":3757,"date":"2026-01-16T10:30:35","date_gmt":"2026-01-16T10:30:35","guid":{"rendered":"https:\/\/www.infobip.com\/developers\/?p=3757"},"modified":"2026-01-16T11:19:17","modified_gmt":"2026-01-16T11:19:17","slug":"implementing-mcp-load-tests-with-grafana-k6","status":"publish","type":"post","link":"https:\/\/www.infobip.com\/developers\/blog\/implementing-mcp-load-tests-with-grafana-k6","title":{"rendered":"Implementing MCP load tests with Grafana k6\u00a0"},"content":{"rendered":"\n

In our previous post<\/a>, we explored why MCP servers require a different approach to load testing. We\u2019ve discussed bursty traffic patterns, the importance of reliability over raw latency, and the functional requirements for simulating real AI agent behaviour.  <\/p>\n\n\n\n

In this post, we\u2019re going to walk you through the practical implementation using  Grafana’s k6<\/a>. <\/p>\n\n\n\n

Setting up virtual users<\/strong> <\/h2>\n\n\n\n

Having identified k6 as our tool of choice, the first step is to configure ramping virtual users, which can be easily defined programmatically with JavaScript. In our case, we’re simulating 100 AI agents progressing through three distinct stages: <\/p>\n\n\n\n

    \n
  1. Gradually increment the number of users during a 30-second period. <\/li>\n<\/ol>\n\n\n\n
      \n
    1. Sustain the load for 30 seconds. <\/li>\n<\/ol>\n\n\n\n
        \n
      1. Quickly and gracefully stop all virtual users within 10 seconds. <\/li>\n<\/ol>\n\n\n\n

        Code for this scenario is as follows: <\/p>\n\n\n\n

        export\u00a0const\u00a0options\u00a0=\u00a0{\u00a0\n\u00a0\u00a0scenarios:\u00a0{\u00a0\n\u00a0\u00a0\u00a0\u00a0llm_spike_test:\u00a0{\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0executor:\u00a0'ramping-vus',\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0startVUs:\u00a00,\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0stages:\u00a0[\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\u00a0duration:\u00a0'30s',\u00a0target:\u00a0100\u00a0},\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\u00a0duration:\u00a0'30s',\u00a0target:\u00a0100\u00a0},\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\u00a0duration:\u00a0'10s',\u00a0target:\u00a00\u00a0},\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0 ],\u00a0\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0gracefulStop:\u00a0'5s',\u00a0\n\u00a0\u00a0\u00a0 },\u00a0\n\u00a0 },\u00a0\n};\u00a0<\/code><\/pre><\/div>\n\n\n\n
        Simulating random idle times<\/strong><\/h2>\n\n\n\n
        Now that our virtual users (simulated AI agents) are set up, we can simulate random idle times. These act as conversational gaps with spikes afterwards, representing the scenario where we wait for a large language model to decide which MCP tools to call in its “thinking phase”. <\/p>\n\n\n\n
        To implement these random gaps, we make each virtual user sleep randomly at the end of its call chain. For this task, we are going to use k6 utils<\/a>: <\/p>\n\n\n\n
        import\u00a0{\u00a0randomIntBetween\u00a0}\u00a0from\u00a0'https:\/\/jslib.k6.io\/k6-utils\/1.2.0\/index.js';\u00a0\n\u00a0\nsleep(randomIntBetween(5,\u00a010));<\/code><\/pre><\/div>\n\n\n\n
        Adding MCP support to k6<\/strong>

        <\/strong>By now you may wonder, “but there isn’t a stable MCP support for k6”,\u00a0that’s\u00a0true. This is the exact\u00a0reason why\u00a0we also like this tool; we\u2019ve\u00a0extended the k6<\/a>\u00a0with MCP support, and the result was\u00a0a\u00a0xk6-infobip-mcp<\/a>\u00a0extension.

        A complete example of MCP load test can be found in\u00a0        this GitHub repo<\/a>.\u00a0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        After running our load test scenario, we got a chart of our load pattern where we can double-check if we got the pattern we wanted.<\/p>\n\n\n\n
        \"mcp
        MCP load pattern chart<\/figcaption><\/figure>\n\n\n\n
        The graph shows how our simulated AI agents ramp up gradually, but with noticeable spikes in HTTP requests. I think we\u2019re ready now to take a look at what the load test results reveal! <\/p>\n\n\n\n
        Load test results<\/h2>\n\n\n\n
        Let’s analyse the outcomes produced by our testing approach to provide some insights into the impact of our load scenarios on system performance.  <\/p>\n\n\n\n
        Grafana\u2019s k6 allows you to view the result in multiple formats, and two of them are output in terminal and an HTML report. <\/p>\n\n\n\n
        For a quick developer-friendly view, I prefer the standard output (see the image below), but different views offer different advantages for interpreting results. <\/p>\n\n\n\n
                 \/\\      Grafana   \/\u203e\u203e\/\n    \/\\  \/  \\     |\\  __   \/  \/\n   \/  \\\/    \\    | |\/ \/  \/   \u203e\u203e\\\n  \/          \\   |   (  |  (\u203e)  |\n \/ __________ \\  |_|\\_\\  \\_____\/\n\n     execution: local\n        script: examples\/mcp-sms.js\n web dashboard: http:\/\/127.0.0.1:5665\n        output: -\n\n     scenarios: (100.00%) 1 scenario, 100 max VUs, 1m15s max duration (incl. graceful stop):\n              * llm_spike_test: Up to 100 looping VUs for 1m10s over 3 stages (gracefulRampDown: 30s, gracefulStop: 5s)\n\n\n\n  \u2588 TOTAL RESULTS\n\n    checks_total.......: 1313    17.480365\/s\n    checks_succeeded...: 100.00% 1313 out of 1313\n    checks_failed......: 0.00%   0 out of 1313\n\n    \u2713 result is not empty\n\n    CUSTOM\n    mcp_call_duration....: avg=127.03ms min=70.44ms med=121.16ms max=340.11ms p(90)=161.7ms p(95)=176.8ms\n    mcp_calls............: 1317    17.533618\/s\n    mcp_errors...........: 0.00%   0 out of 1317\n    mcp_success..........: 100.00% 1317 out of 1317\n\n    HTTP\n    http_req_duration....: avg=104.23ms min=55.38ms med=98.01ms  max=1.08s    p(90)=141.8ms p(95)=157.12ms\n    http_req_failed......: 0.00%   0 out of 3950\n    http_reqs............: 3950    52.587541\/s\n\n    EXECUTION\n    iteration_duration...: avg=8.23s    min=5.47s   med=8.57s    max=10.95s   p(90)=10.59s  p(95)=10.65s\n    iterations...........: 652     8.680273\/s\n    vus..................: 8       min=4            max=100\n    vus_max..............: 100     min=100          max=100\n\n    NETWORK\n    data_received........: 24 MB   319 kB\/s\n    data_sent............: 8.1 MB  108 kB\/s\n\n\n\n\nrunning (1m15.1s), 000\/100 VUs, 652 complete and 8 interrupted iterations\nllm_spike_test \u2713 [======================================] 005\/100 VUs  1m10s<\/code><\/pre><\/div>\n\n\n\n
        From Simulated Load Patterns to Actionable Insights <\/h2>\n\n\n\n
        The output depicted above shows how one MCP call results in multiple HTTP requests. In our case ~17 MCP requests per second resulted in ~52 HTTP requests per second. This significant difference clearly stresses the importance of measuring MCP calls, not just HTTP ones. <\/p>\n\n\n\n
        Unlike the terminal output, the HTML report enables us to efficiently correlate between potential service degradations occurring during peak load events and underlying factors such as network bandwidth constraints. <\/p>\n\n\n\n
        For example, if we had a bandwidth issue, the data transfer rate would plateau at a certain maximum and not exceed that level. However, if you look at the image below, that’s not what we’re seeing. <\/p>\n\n\n\n
        \"mcp
        MCP load test report<\/figcaption><\/figure>\n\n\n\n
        The data transfer rate continues to climb together with the increased load, rather than flattening out. This suggests that, at least in this scenario, bandwidth is not the limiting factor.  <\/p>\n\n\n\n
        By analyzing results from different reports, we were able to identify key performance issues like sudden spikes in duration and errors that could indicate timeouts.  The reports gave us grunt work for identifying key areas of improvement. <\/p>\n\n\n\n
        How did load testing help us improve stability? <\/h2>\n\n\n\n
        Load testing underlined some issues we wouldn\u2019t have caught otherwise. Let me show you in more detail how the results of our load testing provided practical guidance for improving the reliability and stability of our system. <\/p>\n\n\n\n
        Timeouts<\/h3>\n\n\n\n
        As mentioned before, load testing showed us some strange behavior that we couldn’t link to processing issues. <\/p>\n\n\n\n
        By digging deeper, we have seen timeout errors on balancers, but our MCP processing was successful. This indicated that balancers needed bigger timeout values than we had on our longest processing MCP tool. To address this issue, we\u2019ve implemented a cascading timeout strategy.  <\/p>\n\n\n\n
        We configured the public load balancer with the longest timeout duration, while keeping the internal MCP server processing time the shortest. We figured it would make the connection stay open long enough for the server to complete its task. <\/p>\n\n\n\n
        Latency and sticky sessions<\/h3>\n\n\n\n
        Our next issue to tackle was with latency. We\u2019ve noticed that traffic shifted too rapidly between instances based on load. This caused even bigger latencies and broken Server-Side Events. To solve the instance hopping<\/strong>, we\u2019ve introduced sticky sessions<\/a>. <\/p>\n\n\n\n
        Sticky sessions significantly reduced latency by allowing the same AI agent to reuse its session state, which is stored as “warm” data in the server’s fast in-memory cache (RAM). We needed a mechanism to direct subsequent requests to the same server, and we considered two options: route traffic by MCP Session ID header<\/strong><\/a> or by the client IP address. <\/p>\n\n\n\n
        The MCP protocol is relatively new and industry adoption of its latest features is inconsistent. To support the latest features and ensure backward compatibility for existing AI agents built on older versions, we\u2019ve implemented both the Session ID and the IP address strategies for achieving server “stickiness.” <\/p>\n\n\n\n
        This shows us how much value even a simple load test can bring in terms of not only capacity planning but also identifying state issues in high-concurrent systems. <\/p>\n\n\n\n
        What is next?<\/h2>\n\n\n\n
        Although we’ve already had a lot of data to go on, we are not done with expanding load testing capabilities to cover interesting cases like: <\/p>\n\n\n\n