crud and async-db rank the Postgres client, not the framework

[nigrosimone]

The crud rules ask for "a standard async Postgres driver with connection pooling" and leave the choice open, so the row ends up ranking the database client and the HTTP framework almost disappears from it.

From data.json:

• crud-4096: uWebSockets.js 357,544, fulmine 353,456, a 1% difference. The same two entries on baseline-4096 are 2,515,762 and 1,245,654, a factor of two.
• async-db-1024: express 169,687 vs fulmine 227,094, 1.34x. On json-4096 the same two are 395,361 and 1,082,279, 2.7x.
• The top of crud is entries with their own Postgres client: zix has a per-worker pipelined postgres lane, ioxide ships ioxide.pg.

I do not think excluding frameworks without their own driver is the answer, it would empty the profile. What would help: name the driver on the row or in meta.json, or pin one driver per language for standard entries and leave custom clients to tuned, the way compression works.

Same question for async-db and fortunes.

Ref #1103 (not strictly related, but similar)

[MDA2AV]

frameworks that use ioxide which ships a postgres driver are marked as tuned. You can use your own driver, you will be marked as tuned, as genhttp-11-ioxide is. To be marked as standard you need to use an established pg driver, database querying is crucial to a http framework, using a driver instead of an orm already puts more pressure on the framework itself.

Naturally the gap in async-db is much less than in baseline, that is also due to the fact that the postgres container consumes more CPU at higher load, in some cases suffocating the system, there is a plan to reduce the number of CPU cores given to the frameworks for this test to reduce this strain.

When we measure a framework, part of it is the stack/technology it stands on, so for example if Java has a better pg driver for example than Python, it should be rewarded for it as the technology itself is more efficient. A lot of JS or TS frameworks sit on C++ engines which lets them score very high on simple tests but fall off on something that requires more javascript code for example, we need to address this too in the future with tests that exploit more CPU in the framework itself.