Показать сообщение отдельно
Старый 17.12.2019, 12:24   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от kgksoft Посмотреть сообщение
Все верно. Ничего нестандартного в процессе резервирования не использовали. Но вставка, блокировка + обновление медленнее, чем одна операция по обновлению. Это высоконагруженные веб-сервисы и тут каждая лишняя операция в базу данных дорога. А у меня в базе доходит до 90000 операций в секунду.
Ну вот тут не сходится математика. т.е. у вас 5 заказов в секунду, 90к операций, вы оптимизировали 5 обновлений-вставок 1 записи, и говорите что это как-то заметно должно повлиять?
Цитата:
Сообщение от kgksoft Посмотреть сообщение
В моем случае было много параллельных операций по резервированию и разрезервированию товара.
Но ведь параллельные операции InventSum не блокируют, она блокируется в самом конце, т.е. важно сколько параллельных завершений транзакций было и сколько выполнялась проверка остатков в этом завершение транзакции. Вы это замеряли?
Если у вас до 5 позиций, то это проверка должна выполняться мнгновенно и никаких блокировкок быть не должно, ну т.е. вы сами посчитайте, 5 заказов в секунду, наихудший случай, когда в каждом одна и таже аналитика и номенклатура, завершение к примеру идет 100мс (что довольно долго) и то не получается блокировок
НО
В начальных версиях 2012 R3 существовал баг, когда из-за неправильных индексов по InventSumDelta, InventSumDeltaDim эта проверка остатков выбирала неправильный план и выполнялась довольно долго. тогда да, на любой серьезной нагрузке система вставала
Проблема собственно описана https://axology.wordpress.com/2013/1...umdelta-table/ решением было удаление индексов(всех кроме 1) на указанных таблицах
За это сообщение автора поблагодарили: Logger (5), axotnik88 (1).