mssql-jdbc Драйвер JDBC для MS SQL Server подготовил проблему с производительностью кэша операторов в Hikari CP - PullRequest
Новая
       42

mssql-jdbc Драйвер JDBC для MS SQL Server подготовил проблему с производительностью кэша операторов в Hikari CP

0 голосов
/ 02 июня 2018

Мы конвертируем наш сервер из Hibernate 4.2 в Hibernate 5.2 .

Hibernate 5.2 требуется JDBC 4.2 (Java 8) , что требует от нас переключения на Hikari CP пул соединений, который является ответвлением от (1013 * устаревшего) Bone CP , который мы ранее использовали, так как Bone CP поддерживает только до JDBC 4.1 (Java 7) .

В отличие от Bone CP , Hikari CP больше не обеспечивает подготовленныйКэширование операторов в пуле соединений, так что теперь нужно выполнить это в драйвере JDBC , что для MS SQL Server означает, что нам нужно перейти к драйверу JDBC версия, которая обеспечивает подготовленное кэширование операторов в драйвере, и mssql-jdbc 6.4.0 (выпущена в январе 2018 года) является первой с этим.

Таким образом, полное изменение от Hibernate 4.2 + Bone CP 0.8.0 + sqljdbc42 4.2.6420.100 Драйвер JDBC для MS SQL Server до Hibernate 5.2 + Hikari CP 2.7.8 + mssql-jdbc 6.4.0.jre8 .

К сожалению, в результате этого переключения мы наблюдаем среднее значение 20-30% замедления для производительности запросов на чтение - что недопустимо.

Однако в соответствующих результатах для Oracle и MySQL с Hibernate 5.3 + Hikari + их драйверы JDBC мы на самом деле виделио 5-15% улучшении производительности - поэтому мы достаточно уверены, что это не из-за Hibernate (и не может быть Hikari напрямую, так как это не видно, как только нам передается соединение).

Таким образом, мы исследуем проблемы, связанные с переключением с Bone CP 0.8.0 кэширование подготовленных операторов на mssql-jdbc 6.4 подготовленное кэширование операторов.

Мы подтвердили, что производительность ухудшится еще на 10% , если мы включим драйвер mssql-jdbc 6.4 подготовленное заявление кешируется, так что это немного помогает (мы также подтверждаеммед в отладчике, что это на самом деле кеширование).

Мы также попытались настроить все очевидные параметры настройки кэша для него: statementPoolingCacheSize, serverPreparedStatementDiscardThreshold, enablePrepareOnFirstPreparedStatementCall (а также useCursors) с очень небольшим эффектом.

  • Есть ли у кого-нибудь опыт работы с комбинацией Hikari CP + mssql-jdbc 6.4 или в идеале с Hibernate 5 + Hikari CP + mssql-jdbc 6.4?
  • Является ли плохо подготовленная кеширование операторов из mssql-jdbc 6.4 (в сравнении с тем, что использовалось для Bone CP) известной проблемой?Или mssql-jdbc в целом медленнее для запросов на чтение, чем sqljdbc42?
  • Существуют ли какие-либо другие параметры настройки для mssql-jdbc, которые мы пропустили?Кто-нибудь может предложить что-нибудь еще, что мы могли бы попробовать - например, есть ли другой драйвер JDBC для MS SQL Server, который мы могли бы попробовать вместо этого?(jDTS не вариант, так как он не совместим даже с JDBC 4.0)

1 Ответ

0 голосов
/ 01 декабря 2018

Не могу ответить на все эти вопросы напрямую - что помогло улучшить производительность в нашем случае (та же версия драйвера jdbc, которая предоставляется по умолчанию в Spring Boot 2.1) - отключить автокоммит на Hikari.Затем необходимо установить для параметра Hibernate с именем hibernate.connection.provider_disables_autocommit значение true.Это позволяет минимизировать время транзакции.

Обратите внимание, что доступны драйверы 7.x JDBC - можете ли вы проверить, замечаете ли вы те же проблемы?

Если вы используете Spring Boot:Имейте в виду, чтобы установить ‚spring.jpa.open-in-view = false ', чтобы избежать ненужных длинных транзакций (и фактически анти-паттерна).

Это не прямой ответ на ваш вопрос, но это поможетулучшить производительность, используя Mssql и Hibernate.

...