Database Concurrency Workload Replay via Thread Pool Sharing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Databases face challenges in handling increased workloads due to multiple users accessing shared resources simultaneously, as existing methods lack effective simulation and testing for such large concurrent workloads, leading to potential performance issues and resource overuse.

Innovation Solution

A system comprising an application engine with a processor module that simulates multiple active connections to a database, optimizing thread usage by creating a sharable thread pool, allowing different sessions to share threads and reducing resource consumption, thereby enhancing the database's workload capacity testing without overloading hardware resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If multiple threads are created to simulate each session, then the number of simulated sessions increases, but the hardware resources are overloaded and resource consumption increases

Engineering Contradiction:
Improvenumber of simulated sessionsVSAvoidhardware resource consumption
Core Design Contradiction:
Quantity of substanceVSUse of energy by moving object

Solution Approach 1:

Multiple sessions share a common thread pool instead of each session having its own dedicated thread. The application engine creates a limited number of threads that are reused across multiple sessions, combining thread resources to reduce overall hardware consumption while maintaining the ability to simulate many concurrent sessions.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

Threads in the thread pool are designed to be universal and can serve multiple sessions. Each thread can be dynamically assigned to different sessions based on availability, making the thread resource multi-functional rather than dedicated to a single session, thereby reducing total thread requirements.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Ease of operation

If a dedicated thread is created for each session, then session management is simplified, but the device complexity and resource consumption increase

Engineering Contradiction:
Improvesession managementVSAvoidthread pool structure
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

A thread pool manager acts as an intermediary between sessions and threads. Instead of direct one-to-one mapping, the manager mediates thread allocation and session management, handling the complexity of thread reuse, availability tracking, and session assignment internally while presenting a simplified interface for session management.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If more threads are used to increase replay performance, then the number of database transaction statements executed increases, but the hardware resources become overloaded

Engineering Contradiction:
Improvereplay performanceVSAvoidthread count
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The thread pool ensures continuous utilization of thread resources by efficiently allocating available threads to pending database transaction statements. Instead of threads idle or overloaded, the system maintains continuous productive action by dynamically matching thread availability with workload demands, maximizing replay performance within resource constraints.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS11663214B2Replaying large concurrency workload
Publication Date: 2023.05.30 SAP SE
  • US11663214B2 patent drawing
  • US11663214B2 patent drawing
  • US11663214B2 patent drawing

AI summary

Disclosed herein are system, method, and computer program product embodiments for replaying a large concurrency workload. The embodiments disclosed herein may be used to test the workload capacity of a database. An embodiment operates by executing a first database transaction statement to a database. The execution status of the first database transaction statement is checked and the number of work threads connecting to the database is adjusted. In an embodiment, the number of work threads used may be less than the number of sessions simulated.