Когда Ваш проект начинает пользуется популярностью и каждая миллисекунда обработки запроса от пользователя становится критической, приходится искать узкие места в системе. Часто больше всего времени занимает выполнение SQL запроса из приложения к базе данных. Попробуем разобраться, что можно оптимизировать в программе при работе с БД.
Теория
Для лучшего понимания рассмотрим какие шаги выполняются, когда приложение делает запрос к БД, например запрос выборки:
- Открытие соединения к БД и отправка запроса серверу.
- Сервер парсит SQL запрос.
- Сервер оптимизирует запрос исходя из правил, а так же из статистики по таблицам. В результате строится план выполнения запроса.
- Сервер выполняет запрос в соответствии с ранее построенном планом и отправляет результаты пользователю.
На чем же можно сэкономить время?
Первый шаг открытия соединения с сервером, является довольно долгим и мы можем его исключить заранее подготовив пул уже открытых соединений и предоставляя из него соединения приложению по мере необходимости.
Так же можно избежать повторного исполнения шагов два и три если мы будем использовать связанные переменные при написание запросов и кешировать результаты шага три, которые мы получаем от сервера.
В настоящее время большинство драйверов для работы с БД поддерживают работу с пулами соединений. Однако всегда есть соблазн написать свою реализацию, которая будет работать быстрее. Давайте проверим сколько мы выиграем используя пулы соединений и кеширование, как в коробочном решении так и в самописном.
Способ измерения
Для тестов используем свободно распространяемую СУБД PostgreSQL, а клиент напишем на JAVA. В БД создадим небольшую таблицу test.test_table (около 10 строк), состоящую из первичного ключа id и строкового значения value. Пусть у нас клиенты параллельно выполняют запросы к БД, для этого создадим потоки, которые будут делать простые запросы поиска по первичному ключу в этой таблице. При создании потоков мы будем указывать различную реализацию пулов соединений, что позволит нам сравнить производительность, т.к. поток будет считать суммарное время потраченное им на выполнение 100 запросов.
class TestThread extends Thread {
private DBPool pool;
private long workTime = 0;
private long foundStr = 0;
@Override
public void run() {
workTime = System.currentTimeMillis(); // Засекаем время
Connection con = null;
PreparedStatement st = null;
ResultSet rs = null;
Random rnd = new Random();// будем использовать как первичный ключ в запросе
for (int i = 0; i < 100; i++) {
try {
con = pool.getConnection();// получем соединение к БД
// отправляем запрос на парсинг и построение плана выполнения
st = con.prepareStatement("SELECT a.* FROM test.test_table a WHERE id =?");
st.setObject(1, rnd.nextInt(10));
rs = st.executeQuery();// выполняем запрос
if (rs.next()) {
String tmp = (rs.getString(2)); // обрабатываем результат
if (tmp != null) {
foundStr++;
}
}
} catch (SQLException ex) {
//ошибка при выполнении, выводим в консоль
System.out.println("Pool " + pool + " exeption " + ex);
} finally {
// и в конце, аккуратно закрываем все использованные нами объекты
try {
if (rs != null)
rs.close();
} catch (SQLException e) {
//ignore
}
try {
if (st != null)
st.close();
} catch (SQLException e) {
//ignore
}
try {
if (con != null)
pool.putConnection(con); // кладем соединение обратно в пул
} catch (SQLException e) {
//ignore
}
}
}
workTime = System.currentTimeMillis() - workTime; // получаем потраченное время
}
}
Теперь сделаем несколько пулов, и сравним производительность.
Первым будет классический, который на каждый запрос открывает соединение с сервером и после выполнения запроса закрывающий его.
class DBPool {
private String url, user, password;
DBPool(String url, String user, String password) throws ClassNotFoundException {
this.url = url;
this.user = user;
this.password = password;
Class.forName("org.postgresql.Driver");
}
public Connection getConnection() throws SQLException {
return DriverManager.getConnection(url, user, password);
}
public void putConnection(Connection connection) throws SQLException {
connection.close();
}
}
Вторым будет, использующий специальный кеширующий источник данных класс из JDBC драйвера к PostgreSQL — PGPoolingDataSource. Который позволяет задать размер пула соединений, а так же начальное количество соединений. Кроме того в настройках у PreparedStatement есть настройка setPrepareThreshold — отвечающая за количество выполнений запроса, после которого запрос кешируется и не требует парсинга и построения плана выполнения.
class DBPoolCache extends DBPool {
private PGPoolingDataSource source;
DBPoolCache(String host, String database, String user, String password) {
source = new PGPoolingDataSource();
source.setDataSourceName("A Data Source");
source.setServerName(host);
source.setDatabaseName(database);
source.setUser(user);
source.setPassword(password);
source.setMaxConnections(20);//Максимальное значение
source.setInitialConnections(20);//Сколько соединений будет сразу открыто
}
public Connection getConnection() throws SQLException {
return source.getConnection();
}
public void putConnection(Connection connection) throws SQLException {
connection.close();
}
}
Ну и в конце нашу реализацию пулов, когда мы сами кешируем соединения к БД а также результаты разбора SQL запроса (PreparedStatement).
class DBPoolCacheMy extends DBPool {
private String url, user, password;
private PGSimpleDataSource source;
private BlockingQueue<Connection> connections = new ArrayBlockingQueue<Connection>(20);
DBPoolCacheMy(String host, String database, String user, String password) throws SQLException {
source = new PGSimpleDataSource();
source.setServerName(host);
source.setDatabaseName(database);
source.setUser(user);
source.setPassword(password);
for (int i = 0; i < 20; i++) {//Подготавливаем соединения
connections.add(new MyConnection(source.getConnection()));
}
}
public Connection getConnection() throws SQLException {
try { // пробуем получить свободное соединение
return connections.poll(2, TimeUnit.SECONDS);
} catch (InterruptedException e) {
return null;
}
}
public void putConnection(Connection connection) throws SQLException {
connections.add(connection);
}
}
Так же придётся реализовать свой класс соединения с БД, который будет осуществлять кеширование PreparedStatement.
class MyConnection implements Connection {
private Connection connection;
protected MyConnection(Connection connection) {
this.connection = connection;
}
private ConcurrentHashMap<String, PreparedStatement> statements = new ConcurrentHashMap<String, PreparedStatement>();
public PreparedStatement prepareStatement(String sql) throws SQLException {
PreparedStatement statement = statements.get(sql);
if (statement == null) {
statement = new MyStatement(connection.prepareStatement(sql));
statements.put(sql, statement);
}
return statement;
}
.....
}
Плюс свой класс реализующей интерфейс PreparedStatement, и не реагирующий на закрытие
class MyStatement implements PreparedStatement {
private PreparedStatement statement;
MyStatement(PreparedStatement statement) throws SQLException {
this.statement = statement;
((PGStatement) statement).setPrepareThreshold(1);
}
public void close() throws SQLException {
//ignore
}
.....
}
Заключение
Ну и наконец сравним производительность трех различных пулов соединений, запустим тесты с количеством параллельных потоков от 1 до 10, для различных реализаций. В результате получился следующая зависимость общего времени выполнения задачи от количества потоков.
Из графика видно, что кешировать соединения с БД явно нужно, это даёт значительный прирост производительности системы. А вот писать самописную реализацию кеширования соединений и PreparedStatement не даёт ощутимой выгоды.
Автор: WhiteTigera
