Skip to content

Fix for limitation of 99 max connected users

Pavel Kisliak requested to merge epam/db_conn_pool into main

Type of change

  • Bug Fix
  • Feature

Does this introduce a change in the core logic?

  • [Yes]

Does this introduce a change in the cloud provider implementation, if so which cloud?

  • AWS
  • Azure
  • GCP
  • IBM

Updates description

This MR fixes limitation of 99 max connected users described in the issue: #48 (closed)
The main goal is to make the lifetime of DB connections as per request instead per session.

  • Introduce DB connection pool which manages connections and doing some health check
  • Postpone instantiation of protocols from the establishing session time to later request processing
  • Change the lifetime of AdminDb,OpenKVRepo classes and all Proto implementations from per session to per request
  • Move adjustments of protocols capabilities from ServerConfig to Server (because of changed instantiation time of Protos)
  • Move code from OpenKVSession to BaseProto and OpenKVRepo
  • Add special benchmark which simulates high-load client-server interaction (with big amount of connected users 100+)
  • Add Cmake option BUILD_TESTS for able to disable tests (helpful with such big refactoring)
  • Remove legacy admin mode used in transactions (as we agreed in the previous MR)

The main idea that Db connection pool manages connections via the shared_ptr counter, if it's equal 1 then it's free, otherwise - busy.
Each client's request reserves a database connection only when needed (as late as possible).
DB connection is immediately get back to pool after processing request.
ETP transaction reserving DB connection for more long time than request (it's kept in the session).

Special high-load test ClientHighLoad_ArrayGet simulates simultaneous work of 200 clients with a server which runs in 8 threads.

Performance

This change does not sufficiently affect performance +/- 5% (within measurement errors).
There is just reduced for about 37 times establishing user session which does not require DB connection now (and postponed instantiation of protocols).
I think that make sense to cache prepared statements in the DB connection (PostgreSql also should not recreate them, but redundant DB call in any case is not cheap).

Edited by Derek Hudson

Merge request reports