Requests not balanced across replicas when using WithReplicas(2)

piotreksda commented 1 week ago

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug

I'm experiencing an issue where all requests are routed to a single replica, even though I've set .WithReplicas(2) for the apiService. I expected the load to be distributed across both replicas, but instead, it appears to always target only one.

Source code: https://github.com/piotreksda/aspire-tests

Code Sample:

var apiService = builder.AddProject<Projects.AspireSample_ApiService>("apiservice")
    .WithReference(messageBus)
    .WithReference(redisCache)
    .WithHttpsEndpoint(name: "httpsProxies", port: 21372) //same without it
    .WithReplicas(2);

Request: [POST] https://localhost:21372/send-command?content=test-123-123

Replica 1:

Replica 2:

Environment: Device: MacBook (Apple Silicon series) OS: macOS 15.1 Actual Behavior: All requests are routed to a single replica, causing an imbalance in load distribution.

https://github.com/piotreksda/aspire-tests

Expected Behavior

Requests should be distributed across the two replicas specified.

Steps To Reproduce

clone https://github.com/piotreksda/aspire-tests
run with https
send some requests to Request: [POST] https://localhost:21372/send-command?content=test-123-123
logs appears only in one replica

Exceptions (if any)

No response

.NET Version info

dotnet --info .NET SDK: Version: 8.0.401 Commit: 811edcc344 Workload version: 8.0.400-manifests.e0880c5d MSBuild version: 17.11.4+37eb419ad

Runtime Environment: OS Name: Mac OS X OS Version: 15.1 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/8.0.401/

.NET workloads installed: Configured to use loose manifests when installing new manifests. [aspire] Installation Source: SDK 8.0.400 Manifest Version: 8.2.2/8.0.100 Manifest Path: /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2/WorkloadManifest.json Install Type: FileBased

Host: Version: 8.0.8 Architecture: arm64 Commit: 08338fcaa5

.NET SDKs installed: 6.0.425 [/usr/local/share/dotnet/sdk] 7.0.410 [/usr/local/share/dotnet/sdk] 8.0.401 [/usr/local/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.33 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.33 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Anything else?

I use Rider but tried with cli and same behaviour

davidfowl commented 1 week ago

Yes, the load balancer is a tcp one (not an http one), you'll see connections getting round robined but not http requests. Not super useful testing http load balancing. Replicas in aspire require lots more work to be useful for these scenarios.

oising commented 1 week ago

Curious if forcing a "Connection: close" header would defer to the tcp lb?

dotnet / aspire