starred/WireMock.Net
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-08-27 22:04:23 +02:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Requests are very slow (~2.1 sec) - bad performance #321

New Issue
Closed
opened 2025-12-29 08:26:05 +01:00 by adam · 4 comments
adam commented 2025-12-29 08:26:05 +01:00
Owner
Copy Link
Copy Source

Originally created by @narcis-sy on GitHub (Dec 12, 2020).

Describe the bug

Requests to the server are handled very slowly, ~2.1 sec for a simple get.

Expected behavior:

Given that the server is in memory I would expect a response time of less de 50ms.

Test to reproduce

Simple add a stopwatch in any of the tests in https://github.com/WireMock-Net/WireMock.Net/blob/master/test/WireMock.Net.Tests/WireMockServerTests.cs
I only count the request time, not the actual start of the server.

   var s = Stopwatch.StartNew();
            // then
            Check.That(server.Mappings).IsEmpty();
            Check.ThatAsyncCode(() => new HttpClient().GetStringAsync("http://localhost:" + server.Ports[0] + path)).ThrowsAny();
            s.Stop();

This gives 2.1 sec. I've measured the WireMockMiddleware and it takes 62ms. So something is lost on the way.

Other related info

Using xunit for testing

Originally created by @narcis-sy on GitHub (Dec 12, 2020). ### Describe the bug Requests to the server are handled very slowly, ~2.1 sec for a simple get. ### Expected behavior: Given that the server is in memory I would expect a response time of less de 50ms. ### Test to reproduce Simple add a stopwatch in any of the tests in https://github.com/WireMock-Net/WireMock.Net/blob/master/test/WireMock.Net.Tests/WireMockServerTests.cs I only count the request time, not the actual start of the server. ``` var s = Stopwatch.StartNew(); // then Check.That(server.Mappings).IsEmpty(); Check.ThatAsyncCode(() => new HttpClient().GetStringAsync("http://localhost:" + server.Ports[0] + path)).ThrowsAny(); s.Stop(); ``` This gives 2.1 sec. I've measured the `WireMockMiddleware` and it takes 62ms. So something is lost on the way. ### Other related info Using xunit for testing
adam added the invalid label 2025-12-29 08:26:05 +01:00
adam closed this issue 2025-12-29 08:26:05 +01:00
adam commented 2025-12-29 08:26:05 +01:00
Author
Owner
Copy Link
Copy Source

@narcis-sy commented on GitHub (Dec 14, 2020):

This may be something from my local machine. It seems the tests ran by the repos CI/CD run fast. I've tested it also on our CI/CD and they run fast.
It's probably something on my machine, although I did disable every firewall, windows defender, everything.

@narcis-sy commented on GitHub (Dec 14, 2020): This may be something from my local machine. It seems the tests ran by the repos CI/CD run fast. I've tested it also on our CI/CD and they run fast. It's probably something on my machine, although I did disable every firewall, windows defender, everything.
adam commented 2025-12-29 08:26:05 +01:00
Author
Owner
Copy Link
Copy Source

@kaiserbergin commented on GitHub (Mar 4, 2021):

@narcis-sy did you ever figure out your local issue? I realized I was running into a similar issue when I placed timeout policies on my http client requests and started seeing errors in testing.

@kaiserbergin commented on GitHub (Mar 4, 2021): @narcis-sy did you ever figure out your local issue? I realized I was running into a similar issue when I placed timeout policies on my http client requests and started seeing errors in testing.
adam commented 2025-12-29 08:26:06 +01:00
Author
Owner
Copy Link
Copy Source

@narcis-sy commented on GitHub (Mar 5, 2021):

@kaiserbergin Nope :( I happens just locally and just for some people (Win10). I tried disabling firewall everything.. still takes time, idk why.

@narcis-sy commented on GitHub (Mar 5, 2021): @kaiserbergin Nope :( I happens just locally and just for some people (Win10). I tried disabling firewall everything.. still takes time, idk why.
adam commented 2025-12-29 08:26:06 +01:00
Author
Owner
Copy Link
Copy Source

@benagain commented on GitHub (Mar 21, 2021):

I am seeing the same problem - the first request to WireMock from a HttpClient takes ~2 seconds. Subsequent requests from the same HttpClient object are fast, but the first request from a new HttpClient again takes about 2 seconds. This adds up to a fairly dramatic time cost when running our entire test suite.

I am also on Win10, and am using .NetCore 3.1 and 5.0.

I went digging into it, and it turns out to be something to do with requesting "any" IP address when configuring Kestrel options in AspNetCoreSelfHost.NETStandard - at least in my scenario on Win10. That value IPAddress.Any actually means "any IPv4" address, and for some reason I haven't determined that is introducing the delay. If instead we tell Kestrel to use "any IPv4 or IPv6" address then the delay vanishes for me. The Kestel options has a handy ListenAnyIP method which will do this for us, and essentially uses an equivalent of IPAddress.IPv6Any.

Making that change reduces the execution time of any single WireMockServerTest from >2 seconds to 200-300ms.

Running the WireMock test suite itself is fairly dramatic. From:

dotnet test ./test/WireMock.Net.Tests/WireMock.Net.Tests.csproj --no-build --configuration Debug --framework netcoreapp3.1
...
Passed!  - Failed:     0, Passed:   784, Skipped:     8, Total:   792, Duration: *** 5 m 12 s ***

To:

dotnet test ./test/WireMock.Net.Tests/WireMock.Net.Tests.csproj --no-build --configuration Debug --framework netcoreapp3.1
...
Passed!  - Failed:     0, Passed:   784, Skipped:     8, Total:   792, Duration: *** 49 s ***

Note - those test times are misleading, they seem to be the cumulative count of all tests, even though the tests are running concurrently.

@StefH - I will create a PR for my fix to this and it would be great if you're happy to accept it. Please be aware that I am only able to test this on my Windows 10 machine. All of the various flavours do pass all their tests (net452 through netcore5.0) here, but I am not able to verify it on Mac/linux/elsewhere.

@benagain commented on GitHub (Mar 21, 2021): I am seeing the same problem - the first request to WireMock from a `HttpClient` takes ~2 seconds. Subsequent requests from the same `HttpClient` object are fast, but the first request from a new `HttpClient` again takes about 2 seconds. This adds up to a fairly dramatic time cost when running our entire test suite. I am also on Win10, and am using .NetCore 3.1 and 5.0. I went digging into it, and it turns out to be something to do with requesting "any" IP address when configuring Kestrel options in `AspNetCoreSelfHost.NETStandard` - at least in my scenario on Win10. That value `IPAddress.Any` actually means "any IPv4" address, and for some reason I haven't determined that is introducing the delay. If instead we tell Kestrel to use "any IPv4 or IPv6" address then the delay vanishes for me. The Kestel options has a handy `ListenAnyIP` method which will do this for us, and [essentially uses](https://github.com/dotnet/aspnetcore/blob/c925f99cddac0df90ed0bc4a07ecda6b054a0b02/src/Servers/Kestrel/Core/src/AnyIPListenOptions.cs#L16-L17) an equivalent of `IPAddress.IPv6Any`. Making that change reduces the execution time of any single WireMockServerTest from >2 seconds to 200-300ms. Running the WireMock test suite itself is fairly dramatic. From: dotnet test ./test/WireMock.Net.Tests/WireMock.Net.Tests.csproj --no-build --configuration Debug --framework netcoreapp3.1 ... Passed! - Failed: 0, Passed: 784, Skipped: 8, Total: 792, Duration: *** 5 m 12 s *** To: dotnet test ./test/WireMock.Net.Tests/WireMock.Net.Tests.csproj --no-build --configuration Debug --framework netcoreapp3.1 ... Passed! - Failed: 0, Passed: 784, Skipped: 8, Total: 792, Duration: *** 49 s *** Note - those test times are misleading, they seem to be the cumulative count of all tests, even though the tests are running concurrently. @StefH - I will create a PR for my fix to this and it would be great if you're happy to accept it. Please be aware that I am only able to test this on my Windows 10 machine. All of the various flavours do pass all their tests (net452 through netcore5.0) here, but I am not able to verify it on Mac/linux/elsewhere.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No labels invalid
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net#321