Тема уже поднималась: Розница 2.3. Зависает подбор товаров .

Сейчас вопрос вот в чем. Подбор товара вызывается в двух случаях - в РМК и в подборе товаров просто из документа (например, из прихода товаров). И в первом случае зависания хоть и есть, но незначительные, и всех все устраивает. А вот во втором - тормозит конкретно. Где поискать, в чем разница? Обработки, естественно, разные, но никак не могу разобраться.

Можно ли как-нибудь зафиксировать "торможение" (через ЖР - понятно, не получается)?

И там, и там используется Динамический список, только в РМК стоит флажок "Динамическое считывание данных", а в обычном, зависаемом подборе - нет. В этом может быть дело?

Да, и везде используются запросы из справочника Номенклатуры, где есть куча дополнительных реквизитов. Может, что-то не так в индексировании?

(0) индекс полнотекстового удали и заново заполни

(1) Спасибо, попробую.

Вот, нашел еще одну хорошую статью по теме: https://infostart.ru/1c/articles/445857/ .
Посмотрел - а у меня там действительно есть вложенные запросы и условия ГДЕ. Попробую еще так.

(1) Индекс полнотекстового поиска - он один для всех или для каждого пользователя свой?
Извиняюсь, что глупые вопросы, возможно, задаю... Просто у меня такая ситуация, что у некоторых подбор "летает", а у некоторых "тормозит". Входят все по RDP, просто под разными логинами и под разными пользователями.

Как в Рознице настроить обновление индекса ППД для конкретного пользователя?

(3) ППД общий для всех, поэтому любые махинации с ним лучше делать, когда в базе никого нет (утром или вечером)

(5) Обновление индекса ППД настроено на каждые 600 сек. (это в типовой Рознице). Если я поставлю его раз в день, на чем это негативно может отразиться?

Прблема действительно в том, что в определенное время у ВСЕХ пользователей есть зависания, а через определенный промежуток времени - их уже нет. Значит, проблема в фоновых заданиях?

(1) Вы имеете ввиду "Очистить индекс"? И как это может повлиять на производительность?

Если база файловая и размер 3.9 ГБ и при этом тормозит.

1. Сделай веб доступ даже если по РДП.
2. Изучить нагрузку на железо если что апгрейд.
3. Разобраться с фоновыми задачами.
4. Подумать как базу свернуть. Уменьшить размеры.
5. Подумать над тем чтоб базу перевести на скуль. Хотя бы на экспресс.

Все эти пункты в порядке очередности и важности.

+(8) Если код подбора менялся то есть не типовой провести анализ на оптимальность и переделать или отказаться от неких фильтров.

(8) Спасибо, по п.3 разбираюсь, п.5 возможен, поскольку есть SQL-сервер для другой базы.

А вот насчет п.1 - если это Розница, там должен быть доступ к оборудования - сканеры ШК, ФР и т.д. Он из-под веб-приложения работать будут?

Интересно вот еще что.
Подбор начал "тормозить" после обновления. Запросы в динамическом списке что в базе до обновления, что после одинаковые. Может быть так, что после обновления нужно было удалить индекс ППД и заново его заполнить (1), а это просто забыли сделать?

Так если было обновление, после которого стали наблюдаться тормоза, так надо бы не просто обновить ПДД, а удалить все кэши.

(12) А сейчас не поздно?

(10) Все оборудование нормально цепляется вроде  да и код адптирован.
Надо погуглить тебе.

(8) По п.5 "5. Подумать над тем чтоб базу перевести на скуль. Хотя бы на экспресс."

Переход на скуль сильно увеличивает производительность?

(15) http://www.gilev.ru/mssqlvsfile/