Запрос / queryNA ScalaQuery в несколько раз медленнее, чем JDBC? - PullRequest
Новая
       11

Запрос / queryNA ScalaQuery в несколько раз медленнее, чем JDBC?

1 голос
/ 18 июля 2011

В следующих тестах производительности многих запросов этот синхронизированный код JDBC занимает 500-600 мс: 

      val ids = queryNA[String]("select id from account limit 1000").list
      val stmt = session.conn.prepareStatement("select * from account where id = ?")
      debug.time() {
        for (id <- ids) {
          stmt.setString(1, id)
          stmt.executeQuery().next()
        }
      }

Однако при использовании ScalaQuery время уходит> 2 с: 

      val ids = queryNA[String]("select id from account limit 1000").list
      implicit val gr = GetResult(r => ())
      val q = query[String,Unit]("select * from account where id = ?")
      debug.time() {
        for (id <- ids) {
          q.first(id)
        }
      }

После отладки с журналами сервера это происходит из-за того, что PreparedStatements многократно готовятся и не используются повторно.

На самом деле это проблема с производительностью, которую мы ударяли в коде нашего приложения, поэтому мы задаемся вопросом, не упускаем ли мы что-то в отношении того, как правильно использовать подготовленные операторы в ScalaQuery, или если переход к JDBC является Предлагаемый обходной путь.

1 Ответ

1 голос
/ 20 июля 2011

Получил ответ из списка рассылки scalaquery. Вот как спроектирован ScalaQuery - он предполагает, что вы что-то, что обеспечивает пул операторов внизу:

В настоящее время ScalaQuery всегда запрашивает новое PreparedStatement из Соединения. Раньше был кеш для PreparedStatements в ранних версиях, но я удалил его, потому что уже есть хорошие решения для этой проблемы. У каждого приличного пула соединений должна быть опция для пула PreparedStatement. Если вы используете сервер Java EE, он должен иметь интегрированный пул соединений. Для автономных приложений вы можете использовать что-то вроде http://sourceforge.net/projects/c3p0/

...