Comments (6)
@cies Thanks for the suggestion. I like the idea of easily configuring the connection pool, but that one might be too much of a hassle to implement in the growing number of tests that we have.
As for having a consistent pool size across all frameworks, there's probably some benefit to that, and I think in general all frameworks should have their pool set to 256 (which is the highest concurrency that we reach in our tests). I'm hesitant to force that restriction on all frameworks though, in the off chance that a framework does indeed perform better with a different sized pool. I do think it's a worthwhile exercise to ensure that every framework has their connection pool configured and set to a reasonable size.
from frameworkbenchmarks.
As long as the pools are not equal in size for the contenders, the benchmark is testing "default configurations" which is not very interesting.
I think 256 is a bit large for a pool. 10-30 will do for my gut feeling. There are aslo some other conf vars governing the connections (timeouts, minimum size, etc.), best is to set them all to the same values for all FWs.
See:
http://docs.oracle.com/cd/E19316-01/820-4343/abehs/index.html
from frameworkbenchmarks.
Hi @cies. Pat has made a separate issue (#118) for normalizing the connection string used for all the JVM frameworks. So far, in our spot checking, the connection string changes have very little impact. Still, I don't think the tuning options in question will hurt any of the frameworks, so it seems reasonable to normalize this.
Other JDBC configuration options such as transaction isolation level should be managed by the ORM provided by the framework, or in the case of servlet-raw (or any other raw JDBC tests), managed directly in the code.
Where you see 256 as large for a connection pool, I consider it fairly typical. We often deploy applications to production environments with a minimum connection pool size of 200+, reason being our applications tend to use databases for put and get operations and not complex queries. I feel it's fair to say there is not widespread agreement on a good application-agnostic connection pool size (among the hundreds of other tuning parameters for database connectivity and beyond).
Tuning can always be done with knowledge of the application particulars, and we encourage that here, especially in light of a desire to see each framework perform as well as possible. The original spirit of the exercise was to benchmark each framework using what we believed was a reasonable production-grade configuration given the general best-practices prescribed by the framework's documentation. If from there, thanks to community contributions, we end up with more tests that are fine-tuned for the benchmark particulars, I think that's ultimately a good thing. But we do need to keep re-evaluating how and where to paint the line between a standard test and a "stripped" test. I think it's useful to many readers to see how every framework works out of the box when you select its "production" deployment profile (if one exists) versus how it performs with application-specific tuning (which we've called "stripped" here).
All that said, my suspicion is that most frameworks will benefit from having a connection pool sized at least equal to the concurrency level of the test (assuming no server-side concurrency fan-out). Such a configuration allows each of the N requests the opportunity to be begin a query without the risk of waiting for an on-demand connection if the other N-1 requests are all mid-query already.
from frameworkbenchmarks.
256 concurrent users = 256 connections -> not sure this rule should apply for an asynchronous driver
from frameworkbenchmarks.
PostgreSQL recommends ~2*cores connections for optimal throughput. 256 is far too high.
https://wiki.postgresql.org/wiki/Number_Of_Database_Connections
@slorber Handling 256 HTTP requests concurrently does not imply that 256 concurrent database transactions will result in optimal database throughput. A larger number of concurrent queries will increase contention, which increases the amount of work that the database must do. This applies to both a sync and an async driver.
from frameworkbenchmarks.
For the record, it appears that many postgresql benchmarks do not use 256 connections.
Servlet-postgresql-raw uses a default which is 5. (This could probably be set higher for better performance)
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/servlet/src/main/webapp/WEB-INF/resin-web.xml
http://www.caucho.com/resin-3.1/doc/database-tags.xtp#maxcreateconnections
Undertow uses a default too. Not sure what it is.
Aspnet also uses a default. Not sure what it is.
from frameworkbenchmarks.
Related Issues (20)
- Shouldn't pre-computed HTTP headers trigger "Stripped" classification? HOT 7
- Scratch docker permutations
- Python django workload failed after updating the latest version to 4.2.1 HOT 1
- Python 2 EOL in Github Actions. HOT 2
- How to submit your own framework HOT 1
- Using http pipelining HOT 3
- New Citrine Setup Shows Lower Numbers HOT 34
- No longer accepting plaintext only frameworks / Limited number of tests mutations HOT 10
- All frameworks based on Node.js must be tested on the same docker image. HOT 8
- Add "without keep alive" metric HOT 15
- Round 22 Completed HOT 28
- Node & Express Thread Configuration HOT 1
- Flask five times slower in Round 21 than Round 20 HOT 1
- ASP.NET Core platform Json and Plaintext HOT 4
- Round 22 results site shows "woo" test with Racket in the language column whereas it is written in Common Lisp
- New execution mode "profiling" HOT 6
- Enhancement request: disable pg_stat_statements when running anything but validation
- PHP 8.3 update [info]
- Inconsistent composite score best score computation HOT 2
- Holiday Break HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from frameworkbenchmarks.