powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC и CallableStatement
11 сообщений из 11, страница 1 из 1
JDBC и CallableStatement
    #38629446
micoloss
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток!
Тестирую под нагрузкой систему NIO Socket server + PostgreSQL. Пакеты от клиента(100 потоков) и обратно отсылаются каждую секунду и при каждой обработке делается UPDATE текущей сессии в БД через хранимую процедуру (keepalive). Использую пул соединений с БД (PGPoolingDataSource), 20 соединений. В java сервере пакеты обрабатывают 10 потоков. Так вот, профилировщик при просмотре нагрузки на проц, дает что:
Код: java
1.
2.
31,5% - 5 270 s - 2 099 761 inv. java.sql.Connection.prepareCall
23,9% - 4 009 s - 2 099 761 inv. java.sql.CallableStatement.execute



Соответственно, время работы сервера не важно, 10 минут или 2 часа данные в % примерно одинаковые. По скольку мне сравнивать особо не с чем, вот собственно и вопрос - такое поведение JDBC нормально или нет?
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629490
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
micoloss,

Вы путаете нагрузку на CPU и время работы. У вас в профайлере, скорее всего, отображается именно время работы. Вполне ожидаемо что работа с БД составляет огромную часть времени обработки запроса. Ведь нужно запрос преобразовать в протокол работы с БД. Отправить через TCP сокет на сервер. Там распарсить. Обработать, что обычно связано с кучей IO времени. И затем вернуть результат через тот же TCP сокет. То что это заняло значимое время, это ещё не значит что всё это время CPU пыхтел в полную силу.

Если вам критична скорость работы с хранилищем и не так важен SQL, то очевидно стоит использовать какие-то NoSQL решения.
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629501
micoloss
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Blazkowicz,

Вы правы, я не так выразился - я имел ввиду то - что вы написали - время работы. Просто именно из-за этого потоки, которые обрабатывают пакеты, большую часть времени заняты либо блокированы. Хотя если я отрубаю обращение в БД, потоки большую часть находятся в ожидании. Вот и не понятно куда тут копать, java или настройки Postgres. Не хотелось бы менять архитектуру, а вариант с такой интенсивной нагрузкой рассматривается как большую активность клиентов и т.д. Хочется прогнозировать работу сервера при нагрузке и оставлять место для манёвра в случае чего :)
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629542
DEVcoach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BlazkowiczЕсли вам критична скорость работы с хранилищем и не так важен SQL, то очевидно стоит использовать какие-то NoSQL решения.А как тут может помочь NoSQL? Там все то же самое - клиент, протокол, IO. Разницы абсолютно никакой.
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629693
пролетевший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
micoloss,
у нас похожая система - устройства шлют информацию пакетами раз в секунду. Сейчас тысячи, до конца года где то 50000 будет.
Для записи, вначале группируем в памяти по 10 пакетов, потом пишем.
Первая проблема у вас CallableStatement. SQL парсится каждый раз. Должно быть PreparedStatement -> addBatch -> executeBatch. Где то по 10-100 за раз. Скорость возрастет кардинально. Постгрес не очень хорошо обрабатывает много соединений. Оптимально - число ядер умножить на 2-3, больше будет медленнее.
Сейчас пробуем писать в Cassandra, 4 сервера в кластере пишут на пару порядков быстрее SQL.
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629777
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DEVcoachА как тут может помочь NoSQL? Там все то же самое - клиент, протокол, IO. Разницы абсолютно никакой.
Если SQL RDBMS более менее стандартизированы, то NoSQL имеет огромнейшее поле для оптимизаций. Это же целый класс решений, а не что-то конкретное. Можно минимизировать затраты на протокол и избавиться от TCP. IO, конечно, никуда не денется. Разве что если хранилище само реализует очередь и асинхронный API.
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38629789
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
micolossНе хотелось бы менять архитектуру, а вариант с такой интенсивной нагрузкой рассматривается как большую активность клиентов и т.д.
Варианта два. ИМХО, оптимальный - не париться. Количество потоков в современных ОС и железе вполне нормально масштабируется.
Альтернативный - переделать архитекуту на Actor Model. Это звучит круто и интересно. Но выходит боком при отладке больших бизнес-транзакций размазаных по куче асинхронных методов. Модно. Современно. Но эфективно ли?
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38630083
micoloss
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо большое за советы! Буду пробовать.
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38630357
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
micolossПакеты от клиента(100 потоков) и обратно отсылаются каждую секунду и при каждой обработке делается UPDATE текущей сессии в БД через хранимую процедуру (keepalive). Использую пул соединений с БДВаша "работа с пулом" это:
1. Взять соединение из пула;
2. Отпрепарировать запрос;
3. Выполнить запрос;
4. Закрыть соединение и вернуть его в пул
?
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38630531
micoloss
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да
...
Рейтинг: 0 / 0
JDBC и CallableStatement
    #38630574
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Мы пойдём простым логическим ходом".
Аксиома: Соединение возвращается в пул не тогда, когда выполнена итерация цикла, а тогда, когда эта соединение более не требуется
Следствие: Если "... в цать потоков ... update ...", то соединение требуется постоянно, а значит правильный (псевдо)код выглядит так:
1. Забрать соединение из пула
2. Отпрепарировать запрос
3. Забрать очередной набор параметров и выполнить параметризованный запрос
4. Повторять пункт три, пока не возникнет пауза на, хотя бы, минуту или очередная итерация не вернёт ошибку.

P.S. Я понимаю, что этот вариант сложнее, чем копипаст из учебника, но он:
1. Уменьшает нагрузку на СП и на СУБД
2. Уменьшает конкуренцию в базе
3. Хорошо масштабируется.
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC и CallableStatement
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]