Пул соединений JDBC для SQL Server: DBCP vs C3P0 vs No Pooling

Question

У меня есть Java Webapp, который слишком много общается с базой данных SQL Server. Я хочу решить, как эффективно управлять соединениями с этой БД. Первый вариант, который появляется на ум, - это объединение пулов сторонних поставщиков. Я выбрал C3P0 и ГСБД и подготовили несколько тестов, чтобы сравнить эти подходы следующим образом:

Нет Пулы:

public static void main(String[] args) { 
     long startTime=System.currentTimeMillis(); 
     try { 
      for (int i = 0; i < 100; i++) { 
       Connection conn = ConnectionManager_SQL.getInstance().getConnection(); 

       String query = "SELECT * FROM MyTable;"; 
       PreparedStatement prest = conn.prepareStatement(query); 

       ResultSet rs = prest.executeQuery(); 
       if (rs.next()) { 
        System.out.println(i + ": " + rs.getString("CorpName")); 
       } 
       conn.close(); 
      } 
     } catch (Exception e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 
     System.out.println("Finished in: "+(System.currentTimeMillis()-startTime)+" milli secs"); 
    } 

ДБХП:

public static void main(String[] args) { 
     long startTime=System.currentTimeMillis(); 
     try { 
      for (int i = 0; i < 100; i++) { 
       Connection conn = ConnectionManager_SQL_DBCP.getInstance().getConnection(); 

       String query = "SELECT * FROM MyTable;"; 
       PreparedStatement prest = conn.prepareStatement(query); 

       ResultSet rs = prest.executeQuery(); 
       if (rs.next()) { 
        System.out.println(i + ": " + rs.getString("CorpName")); 
       } 
       conn.close(); 
      } 
     } catch (Exception e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 
     System.out.println("Finished in: "+(System.currentTimeMillis()-startTime)+" milli secs"); 
    } 

C3P0:

public static void main(String[] args) { 
     long startTime=System.currentTimeMillis(); 
     try { 
      for (int i = 0; i < 100; i++) { 
       Connection conn = ConnectionManager_SQL_C3P0.getInstance().getConnection(); 

       String query = "SELECT * FROM MyTable;"; 
       PreparedStatement prest = conn.prepareStatement(query); 

       ResultSet rs = prest.executeQuery(); 
       if (rs.next()) { 
        System.out.println(i + ": " + rs.getString("CorpName")); 
       } 
       conn.close(); 
      } 
     } catch (Exception e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 
     System.out.println("Finished in: "+(System.currentTimeMillis()-startTime)+" milli secs"); 
    } 

И Вот результаты:

Max Pool size for c3p0 and dbcp=10 
c3p0: 5534 milli secs 
dbcp: 4807 milli secs 
No Pooling: 2660 milli secs 

__

Max Pool size for c3p0 and dbcp=100 
c3p0: 4937 milli secs 
dbcp: 4798 milli secs 
No Pooling: 2660 milli secs 

Можно сказать, инициализации и запуска время объединения библиотек могут повлиять на результаты этих тестов. Я повторил их с большими числами в цикле, и результаты почти одинаковы.

Удивительно, что метод объединения не намного быстрее, чем методы объединения пулов. Хотя я предполагаю, что когда мы физически закрываем соединение, получение нового должно быть более трудоемким.

Итак, что здесь происходит?

EDIT_01: C3P0 и ГСБД конфигурации

c3p0:

cpds.setMinPoolSize(5); 
cpds.setAcquireIncrement(5); 
cpds.setMaxPoolSize(100); 
cpds.setMaxStatements(1000); 

ДБХП:

basicDataSource.setMinIdle(5); 
basicDataSource.setMaxIdle(30); 
basicDataSource.setMaxTotal(100); 
basicDataSource.setMaxOpenPreparedStatements(180); 

Остальные конфигурации оставлены по умолчанию. Стоит упомянуть, что все соединения установлены для БД на локальном хосте.

Answer 1

c3p0 не является более опасным, чем дорнора. Он старый, но (несколько) активно поддерживается. Являются ли новые альтернативы более подходящими для вашего приложения, вам решать.

Какую версию c3p0 вы используете? Если вы считаете, что это мертвее, чем ругань, вы используете старую версию? Вы должны использовать 0.9.5.2.

Результат теста, который вы определили, будет сильно зависеть от множества трудностей, которые могут быть оценены с помощью предоставленной вами информации. Как указывает Марк Роттевель, вы не указали какую-либо информацию о своей конфигурации. Вы ничего не сказали о расположении SQL Server. Вы увидите большую выгоду от пула соединений, когда база данных удалена, чем когда она является локальной, поскольку некоторые из улучшений производительности связаны с амортизацией сетевой латентности подключения при использовании нескольких клиентов. Ваш тест выполняет запрос и выполняет итерацию через результирующий набор. Чем длиннее набор результатов, тем больше вы увидите накладные расходы из пула соединений (который должен проксировать ResultSet) превысить преимущества более быстрого подключения. (Номера, которые вы получаете, выглядят необычно плохо, однако. C3p0 обычно имеет очень быструю производительность Transult ResultSet.) При достаточно длинных запросах стоимость приобретения Connection становится пренебрежимо малой, если итерация через ResultSet увеличивает накладные расходы библиотеки пула, что делает пул соединений не очень полезным.

Но это далеко не типичный вариант использования для веб-клиентов или мобильных клиентов, которые обычно делают короткие запросы, вставки и обновления. Для коротких запросов, вставок и обновлений стоимость de novo Получение соединения может быть очень большим по сравнению с выполнением запроса. Это прецедент, для которого пулы соединений предлагают значительное улучшение. Возможно, это не то, что вы тестируете; это зависит от того, насколько велика MyTable.