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

New Issue

Closed

opened 2025-12-29 15:20:39 +01:00 by adam · 4 comments

adam commented 2025-12-29 15:20:39 +01:00

Owner

Copy Link

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 15:20:39 +01:00

adam closed this issue 2025-12-29 15:20:39 +01:00

adam commented 2025-12-29 15:20:41 +01:00

Author

Owner

Copy Link

@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 15:20:41 +01:00

Author

Owner

Copy Link

@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 15:20:41 +01:00

Author

Owner

Copy Link

@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 15:20:41 +01:00

Author

Owner

Copy Link

@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.

adam referenced this issue 2025-12-29 15:33:41 +01:00

[PR #320] [MERGED] Remove coverlet folder from source control #853

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

mime-part-matcher

version-2.x

MappingSerializer

1341-mapping-json

stef-aspire-tests-updates

bug/973-TinyMapper

bug/1149-AppendGuidToSavedMappingFile

feature/1150-DockerImageVersion

61

stef-1108

stef-1097

stef-1083-MessageOptions_Type_Conflict

stef-1062-logger

stef-IgnoreOpenApiErrors

stef-928-TypeLoadException-FluentAssertions-net472

nunit

stef-849

stef-847-regex-questionmark

http_verb

WireMockServerContext

webapp

ai

CommandLineArgumentsParser

1.23.0

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.0

1.15.0

1.14.0

1.13.0

1.12.0

1.11.2

1.11.0

1.10.1

1.10.0

1.9.1

1.9.0

1.8.18

1.8.17

1.8.16

1.8.15

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.3

1.8.2

1.8.1

1.8.0

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.12

1.6.11

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.62

1.5.61

1.5.60

1.5.59

1.5.58

1.5.57

1.5.56

1.5.55

1.5.54

1.5.53

1.5.52

1.5.51

1.5.50

1.5.49

1.5.48

1.5.47

1.5.46

1.5.45

1.5.44

1.5.43

1.5.42

1.5.41

1.5.40

1.5.39

1.5.38

1.5.37

1.5.36

1.5.35

1.5.34

1.5.33

1.5.32

1.5.31

1.5.30

1.5.29

1.5.28

1.5.27

1.5.26

1.5.25

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.43

1.4.42

1.4.41

1.4.40

1.4.39

1.4.38

1.4.37

1.4.36

1.4.35

1.4.34

1.4.33

1.4.32

1.4.31

1.4.30

1.4.29

1.4.28

1.4.27

1.4.26

1.4.25

1.4.24

1.4.23

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.10

1.3.9

1.3.8

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11.0

1.2.10

1.2.9.0

1.2.8.0

1.2.7.0

1.2.6.0

1.2.5.0

1.2.4.0

1.2.3.0

1.2.2.0

1.2.1.0

1.2.0.0

1.1.10

1.1.9.0

1.1.8.0

1.1.7.0

1.1.6.0

1.1.5.0

1.1.3.0

1.1.2.0

1.1.1.0

1.1.0.0

1.0.43.0

1.0.42.0

1.0.41.0

1.0.40.0

1.0.39.0

1.0.38.0

1.0.37.0

1.0.36.0

1.0.35.0

1.0.34.0

1.0.33.0

1.0.32.0

1.0.31.0

1.0.29.0

1.0.28.0

1.0.25.0

1.0.24.0

1.0.23.0

1.0.22.0

1.0.21.0

1.0.20.0

1.0.19.0

1.0.18.0

1.0.17.0

1.0.16.0

1.0.15.0

1.0.14.0

1.0.13.0

1.0.12.0

1.0.11.0

1.0.10.0

1.0.9.0

1.0.8.0

1.0.7.0

1.0.6.1

1.0.6

1.0.5

1.0.4.21

1.0.4.20

1.0.4.19

1.0.4.18

1.0.4.17

1.0.4.16

1.0.4.15

1.0.4.14

1.0.4.13

1.0.4.12

1.0.4.11

1.0.4.10

1.0.4.9

1.0.4.8

1.0.4.7

1.0.4.6

1.0.4.5

1.0.4.4

1.0.4.3

1.0.4.2

1.0.4.1

1.0.4.0

1.0.3.20

1.0.3.19

1.0.3.18

1.0.3.17

1.0.3.16

1.0.3.15

1.0.3.14

1.0.3.13

1.0.3.12

1.0.3.11

1.0.3.10

1.0.3.9

1.0.3.8

1.0.3.7

1.0.3.6

1.0.3.5

1.0.3.4

1.0.3.3

1.0.3.2

1.0.3.1

1.0.3.0

1.0.2.13

1.0.2.12

1.0.2.11

1.0.2.10

1.0.2.9

1.0.2.8

1.0.2.7

1.0.2.6

1.0.2.5

1.0.2.4

1.0.2.1

1.0.2.0

1.0.1.5

1.0.1.3

1.0.1.2

1.0.1.1

1.0.0.0

Labels

Clear labels

bug

bug

doc

doc

duplicate

feature

feature

invalid

pull-request

Mirrored from GitHub Pull Request

question

wontfix

No Label invalid

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

adam

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#320