Update connection strings used for ASP.NET Core

[NinoFloris]

Pending merge aspnet/Benchmarks#1667 (review)

Updates connection strings to use a tuned maximum of db connections, and enables multiplexing for non-platform scenarios.

/cc @sebastienros @benaadams @roji

[sebastienros]

When it's merge we'll need to compare all the results, since TE runs with different number of connections, while our internal ones have a fixed number (256).

[sebastienros]

Update EF is broken. Pretty sure I had disabled it and filed an issue on EF with the concern. Like it's detecting an object doesn't need to change and is not sending the update. The TE CI steps counts the expected statements.

[roji]

@sebastienros don't remember anything about this... We don't have update EF in aspnet/Benchmarks, right?

In any case, EF would be pretty slow here, with the entire change tracking mechanism coming into play :)

[sebastienros]

@roji right, that's why I was pretty sure I had disabled it.

@NinoFloris can you remove the two ef-updates sections in the benchmark_config.json file so the tests pass?

[sebastienros]

And probably also aspnetcore.mw-ef-pg-up.dockerfile and aspnetcore.mvc-ef-pg-up.dockerfile that are only use by these scenarios

[NinoFloris]

@sebastienros done, it needs an approval to run CI

[NinoFloris]

@sebastienros it's green!

[benaadams]

What about all the others? 😉

[lauxjpn]

Update EF is broken. Pretty sure I had disabled it and filed an issue on EF with the concern. Like it's detecting an object doesn't need to change and is not sending the update. The TE CI steps counts the expected statements.

@sebastienros don't remember anything about this... We don't have update EF in aspnet/Benchmarks, right?

In any case, EF would be pretty slow here, with the entire change tracking mechanism coming into play :)

In my benchmark run for #6566 (also discussed there), the RAW aspcore-ado-pg-up benchmark had the same issue. So I suspect, that PostgreSQL might count the updates inaccurately under heavy pressure (e.g. a non-interlocked increment), as EF Core is not involved there at all:

Excerpt from benchmark run

Running Test: aspcore-ado-pg-up
--------------------------------------------------------------------------------
aspcore-ado-pg-up: Step 1/11 : FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
aspcore-ado-pg-up:  ---> bd73c72c93a1
aspcore-ado-pg-up: Step 2/11 : WORKDIR /app
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 5b59283f811b
aspcore-ado-pg-up: Step 3/11 : COPY PlatformBenchmarks .
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 76bca5a913b7
aspcore-ado-pg-up: Step 4/11 : RUN dotnet publish -c Release -o out /p:IsDatabase=true
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 214c503a9ce3
aspcore-ado-pg-up: Step 5/11 : FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS runtime
aspcore-ado-pg-up:  ---> 36007796eeee
aspcore-ado-pg-up: Step 6/11 : ENV ASPNETCORE_URLS http://+:8080
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 0af436f2c33b
aspcore-ado-pg-up: Step 7/11 : WORKDIR /app
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 3676f87d7261
aspcore-ado-pg-up: Step 8/11 : COPY --from=build /app/out ./
aspcore-ado-pg-up:  ---> Using cache
aspcore-ado-pg-up:  ---> 279cac97bc4e
aspcore-ado-pg-up: Step 9/11 : COPY PlatformBenchmarks/appsettings.postgresql.updates.json ./appsettings.json
aspcore-ado-pg-up:  ---> 993f10138558
aspcore-ado-pg-up: Step 10/11 : EXPOSE 8080
aspcore-ado-pg-up:  ---> Running in c48d0bbcfd8a
aspcore-ado-pg-up: Removing intermediate container c48d0bbcfd8a
aspcore-ado-pg-up:  ---> 9327b1237266
aspcore-ado-pg-up: Step 11/11 : ENTRYPOINT ["dotnet", "PlatformBenchmarks.dll"]
aspcore-ado-pg-up:  ---> Running in a9294c208fc0
aspcore-ado-pg-up: Removing intermediate container a9294c208fc0
aspcore-ado-pg-up:  ---> c2df051e0970
aspcore-ado-pg-up: [Warning] One or more build-args [TFB_TEST_DATABASE TFB_TEST_NAME BENCHMARK_ENV] were not consumed
aspcore-ado-pg-up: Successfully built c2df051e0970
aspcore-ado-pg-up: Successfully tagged techempower/tfb.test.aspcore-ado-pg-up:latest
aspcore-ado-pg-up: Build time: 2s
aspcore-ado-pg-up: Kestrel Platform-Level Application
aspcore-ado-pg-up: /fortunes
aspcore-ado-pg-up: /db
aspcore-ado-pg-up: /updates/
aspcore-ado-pg-up: /queries/
aspcore-ado-pg-up: Database: PostgreSql
aspcore-ado-pg-up: ConnectionString: Server=tfb-database;Database=hello_world;User Id=benchmarkdbuser;***;Maximum Pool Size=64;NoResetOnClose=true;Enlist=false;Max Auto Prepare=3;Multiplexing=true;Write Coalescing Delay Us=500;Write Coalescing Buffer Threshold Bytes=1000
aspcore-ado-pg-up: Caching Populated
aspcore-ado-pg-up: Options: WaitForData=False, PreferInlineScheduling=False, IOQueue=2
aspcore-ado-pg-up: Hosting environment: Production
aspcore-ado-pg-up: Content root path: /app/
aspcore-ado-pg-up: Now listening on: http://[::]:8080
aspcore-ado-pg-up: Application started. Press Ctrl+C to shut down.
aspcore-ado-pg-up: Verifying framework URLs
--------------------------------------------------------------------------------
VERIFYING UPDATE
--------------------------------------------------------------------------------
Accessing URL http://tfb-server:8080/updates/2: 
Accessing URL http://tfb-server:8080/updates/2: 
Accessing URL http://tfb-server:8080/updates/0: 
Accessing URL http://tfb-server:8080/updates/0: 
Accessing URL http://tfb-server:8080/updates/foo: 
Accessing URL http://tfb-server:8080/updates/foo: 
Accessing URL http://tfb-server:8080/updates/501: 
Accessing URL http://tfb-server:8080/updates/501: 
Accessing URL http://tfb-server:8080/updates/: 
Accessing URL http://tfb-server:8080/updates/: 
--------------------------------------------------------------------------------
VERIFYING QUERY COUNT FOR http://tfb-server:8080/updates/20
--------------------------------------------------------------------------------
** SIEGE 4.0.4
** Preparing 512 concurrent users for battle.
The server is now under siege...
Transactions:		         511 hits
Availability:		       99.80 %
Elapsed time:		        2.45 secs
Data transferred:	        0.31 MB
Response time:		        1.09 secs
Transaction rate:	      208.57 trans/sec
Throughput:		        0.13 MB/sec
Concurrency:		      226.45
Successful transactions:         511
Failed transactions:	           1
Longest transaction:	        2.43
Shortest transaction:	        0.07
 

   PASS for http://tfb-server:8080/updates/20
     Executed queries: 20466/20480
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
   PASS for http://tfb-server:8080/updates/20
     Rows read: 10128/10240
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
   FAIL for http://tfb-server:8080/updates/20
     Only 10114 rows updated in the database out of roughly 10240 expected.
     See https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview#specific-test-requirements
{'Date': 'Wed, 05 May 2021 14:13:22 GMT', 'Content-Length': '33', 'Content-Type': 'application/json', 'Server': 'K'}
[{"Id":2347,"RandomNumber":1804}]
Auditing /FrameworkBenchmarks/frameworks/CSharp/aspnetcore:
No problems to report
aspcore-ado-pg-up: Build time: 2s
aspcore-ado-pg-up: Time starting database: 1s
aspcore-ado-pg-up: Time until accepting requests: 15s
aspcore-ado-pg-up: Verify time: 17s
aspcore-ado-pg-up: Failed verify!
aspcore-ado-pg-up: Total test time: 38s

We have the same issue with the MySQL benchmarks, also the RAW ones (see PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#1408 (comment)), but someone did implement a (suboptimal but "working") error margin for them in the past, so they don't fail verification.

(I also checked for MySQL, whether UPDATE commands that don't need to actually change anything are counted, which is the case.)

So I am questioning, that this is an EF Core issue. I think it is a database status variable counting issue. (Though the fact that this would be an issue in two different database servers is a bit odd. If it is not, it might be a timing related issue.)

In any case, EF would be pretty slow here, with the entire change tracking mechanism coming into play :)

That is more of a reason to expose it with a benchmark, so users can make informed decisions on what ORM to use for their particular needs.

[roji]

In any case, EF would be pretty slow here, with the entire change tracking mechanism coming into play :)

That is more of a reason to expose it with a benchmark, so users can make informed decisions on what ORM to use for their particular needs.

Am definitely not saying we should make it work. Are you working in that area as well for MySQL?

[lauxjpn]

[Will restructure this.]