Анатомия пула соединений

Вступление

Все проекты, над которыми я работал, использовали пул соединений с базой данных, и это по очень веским причинам. Иногда мы можем забыть, почему мы используем один шаблон проектирования или определенную технологию, поэтому стоит отступить и рассуждать об этом. У каждой технологии или технологического решения есть как положительные, так и отрицательные стороны, и если вы не видите каких-либо недостатков, вам нужно задуматься, чего вам не хватает.

Жизненный цикл подключения к базе данных

Каждая операция чтения или записи базы данных требует подключения. Итак, давайте посмотрим, как выглядит поток подключения к базе данных:

Поток идет так:

1. Уровень данных приложения запрашивает источник данных для соединения с базой данных
2. Источник данных будет использовать драйвер базы данных, чтобы открыть соединение с базой данных.
3. Соединение с базой данных создано и TCP-сокет открыт
4. Приложение читает / пишет в базу данных
5. Соединение больше не требуется, поэтому оно закрыто
6. Розетка закрыта

Вы можете легко сделать вывод, что открытие / закрытие соединений довольно дорогая операция. PostgreSQL использует отдельный процесс ОС для каждого клиентского соединения, поэтому высокая скорость открытия / закрытия соединений будет создавать нагрузку для вашей системы управления базами данных.

Наиболее очевидные причины для повторного использования соединения с базой данных:

• сокращение накладных расходов ввода-вывода ОС системы управления приложениями и базами данных при создании / разрушении TCP-соединения
• уменьшение мусора объекта JVM

Объединение в пул без объединения

Давайте сравним сравнение решения без пула с HikariCP, который, вероятно, является самой быстрой из доступных сред пула соединений .

Тест откроет и закроет 1000 соединений.

private static final Logger LOGGER = LoggerFactory.getLogger(<span class="skimlinks-unlinked">DataSourceConnectionTest.class</span>);
 
private static final int MAX_ITERATIONS = 1000;
 
private Slf4jReporter logReporter;
 
private Timer timer;
 
protected abstract DataSource getDataSource();
 
@Before
public void init() {
    MetricRegistry metricRegistry = new MetricRegistry();
    this.logReporter = Slf4jReporter
            .forRegistry(metricRegistry)
            .outputTo(LOGGER)
            .build();
    timer = <span class="skimlinks-unlinked">metricRegistry.timer("connection</span>");
}
 
@Test
public void testOpenCloseConnections() throws SQLException {
    for (int i = 0; i < MAX_ITERATIONS; i++) {
        Timer.Context context = <span class="skimlinks-unlinked">timer.time</span>();
        getDataSource().getConnection().close();
        <span class="skimlinks-unlinked">context.stop</span>();
    }
    logReporter.report();
}

На графике отображается время, затраченное на открытие и закрытие соединений, поэтому чем ниже, тем лучше.

Пул соединений составляет 600 раз s быстрее , чем никаких скоплений альтернативы. Наша корпоративная система состоит из десятков приложений, и только одна система пакетного процессора может выдавать более 2 миллионов соединений с базой данных в час, поэтому стоит подумать об оптимизации на 2 порядка.