|
|
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Тестирую под нагрузкой систему NIO Socket server + PostgreSQL. Пакеты от клиента(100 потоков) и обратно отсылаются каждую секунду и при каждой обработке делается UPDATE текущей сессии в БД через хранимую процедуру (keepalive). Использую пул соединений с БД (PGPoolingDataSource), 20 соединений. В java сервере пакеты обрабатывают 10 потоков. Так вот, профилировщик при просмотре нагрузки на проц, дает что: Код: java 1. 2. Соответственно, время работы сервера не важно, 10 минут или 2 часа данные в % примерно одинаковые. По скольку мне сравнивать особо не с чем, вот собственно и вопрос - такое поведение JDBC нормально или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2014, 21:01 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
micoloss, Вы путаете нагрузку на CPU и время работы. У вас в профайлере, скорее всего, отображается именно время работы. Вполне ожидаемо что работа с БД составляет огромную часть времени обработки запроса. Ведь нужно запрос преобразовать в протокол работы с БД. Отправить через TCP сокет на сервер. Там распарсить. Обработать, что обычно связано с кучей IO времени. И затем вернуть результат через тот же TCP сокет. То что это заняло значимое время, это ещё не значит что всё это время CPU пыхтел в полную силу. Если вам критична скорость работы с хранилищем и не так важен SQL, то очевидно стоит использовать какие-то NoSQL решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2014, 22:06 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Вы правы, я не так выразился - я имел ввиду то - что вы написали - время работы. Просто именно из-за этого потоки, которые обрабатывают пакеты, большую часть времени заняты либо блокированы. Хотя если я отрубаю обращение в БД, потоки большую часть находятся в ожидании. Вот и не понятно куда тут копать, java или настройки Postgres. Не хотелось бы менять архитектуру, а вариант с такой интенсивной нагрузкой рассматривается как большую активность клиентов и т.д. Хочется прогнозировать работу сервера при нагрузке и оставлять место для манёвра в случае чего :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2014, 22:33 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
BlazkowiczЕсли вам критична скорость работы с хранилищем и не так важен SQL, то очевидно стоит использовать какие-то NoSQL решения.А как тут может помочь NoSQL? Там все то же самое - клиент, протокол, IO. Разницы абсолютно никакой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2014, 23:56 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
micoloss, у нас похожая система - устройства шлют информацию пакетами раз в секунду. Сейчас тысячи, до конца года где то 50000 будет. Для записи, вначале группируем в памяти по 10 пакетов, потом пишем. Первая проблема у вас CallableStatement. SQL парсится каждый раз. Должно быть PreparedStatement -> addBatch -> executeBatch. Где то по 10-100 за раз. Скорость возрастет кардинально. Постгрес не очень хорошо обрабатывает много соединений. Оптимально - число ядер умножить на 2-3, больше будет медленнее. Сейчас пробуем писать в Cassandra, 4 сервера в кластере пишут на пару порядков быстрее SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 09:06 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
DEVcoachА как тут может помочь NoSQL? Там все то же самое - клиент, протокол, IO. Разницы абсолютно никакой. Если SQL RDBMS более менее стандартизированы, то NoSQL имеет огромнейшее поле для оптимизаций. Это же целый класс решений, а не что-то конкретное. Можно минимизировать затраты на протокол и избавиться от TCP. IO, конечно, никуда не денется. Разве что если хранилище само реализует очередь и асинхронный API. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 10:04 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
micolossНе хотелось бы менять архитектуру, а вариант с такой интенсивной нагрузкой рассматривается как большую активность клиентов и т.д. Варианта два. ИМХО, оптимальный - не париться. Количество потоков в современных ОС и железе вполне нормально масштабируется. Альтернативный - переделать архитекуту на Actor Model. Это звучит круто и интересно. Но выходит боком при отладке больших бизнес-транзакций размазаных по куче асинхронных методов. Модно. Современно. Но эфективно ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 10:10 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
Спасибо большое за советы! Буду пробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 13:32 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
micolossПакеты от клиента(100 потоков) и обратно отсылаются каждую секунду и при каждой обработке делается UPDATE текущей сессии в БД через хранимую процедуру (keepalive). Использую пул соединений с БДВаша "работа с пулом" это: 1. Взять соединение из пула; 2. Отпрепарировать запрос; 3. Выполнить запрос; 4. Закрыть соединение и вернуть его в пул ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 16:12 |
|
||
|
JDBC и CallableStatement
|
|||
|---|---|---|---|
|
#18+
"Мы пойдём простым логическим ходом". Аксиома: Соединение возвращается в пул не тогда, когда выполнена итерация цикла, а тогда, когда эта соединение более не требуется Следствие: Если "... в цать потоков ... update ...", то соединение требуется постоянно, а значит правильный (псевдо)код выглядит так: 1. Забрать соединение из пула 2. Отпрепарировать запрос 3. Забрать очередной набор параметров и выполнить параметризованный запрос 4. Повторять пункт три, пока не возникнет пауза на, хотя бы, минуту или очередная итерация не вернёт ошибку. P.S. Я понимаю, что этот вариант сложнее, чем копипаст из учебника, но он: 1. Уменьшает нагрузку на СП и на СУБД 2. Уменьшает конкуренцию в базе 3. Хорошо масштабируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2014, 20:10 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38629542&tid=2127249]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
161ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 441ms |

| 0 / 0 |
