ПОЧЕМУ ВРЕМЯ ЗАПРОСА ИЗМЕНИЛОСЬ?

НАМ попрежнему задают порой очень риторические вопросы, ожидая получить «новый» ответ.

Т.е. люди расчитывают, что есть НЕИЗВЕСТНЫЙ ИМ МЕТОД, и если они его узнают, то сразу решат все свои проблемы.
Основная ошибка их заключается в том, что они НЕ ХОТЯТ вникать в детали и суть  ИЗВЕСТНЫХ ИМ МЕТОДОВ.Давайте приведу пример.
Вопрос:
Почему время запроса изменилось?

Давайте раскрою цепочку моих рассуждений.
Сначало нарисуем глобальные факторы, а потом будем их детализировать:
1. На производительность влияет железо;
2. Запрос выполняется все таки софтом, значит он прежде всего опеределяет результат;
3. На скорость исполнения запроса влияет не только как он физически будет исполняться, но с КАКИМИ ДАННЫМИ он будет работать.
4. Неверная и необъективная (ошибочная) оценка замеров производительности тоже может иметь место.

Это глобально, теперь давайте попробуем детализировать:
I. Железо
I.1 — железо может быть модифицировано (причем технический специалист может так не считать, т.е. замена одного жесткого диска от произвоидтеля Х на железо от производителя Y он может посчитать равнозначным если скажем оба производителя маркетингово написали, что у обоиз скорость 36 папугаев).
I.2 — на данное железо добавлена новая функциональная роль и загруженность сервера изменилась, но общих счетчиках производительности это сразу не видно, например нагрузка на дисковую подсистему раньше была 10 очередей в секунду, но это были 9 очередей на чтение и одно на запись, а теперь стало 5 очередей на чтение и пять на запись).
I.3 — есть некоторые параметры железа типа «повербуста» для нехалемов, которые заставляют работать железо в разные моменты времени из-за разного потребления энергия с разной скоростью
I.4 — забывается, что производительность может измеряться не только пропускной способностью, но и шириной одновременной обработки данных. Если вместо 40 пользоватеолей сервер стал обрабатывать 80 пользователей, до на аппаратном уровне возможны «очереди» к любым из ресурсов. В СЕРВЕРЕ ВСЕГДА ЕСТЬ УЗКОЕ МЕСТО!
I.5 — я очень редко замечал, когда измеряется загруженность сетевых каналов, а ведь они также могут быть узким местом; очень часто специалисты делают выводы не имея полной картины загруженности серверов!

Таким образом, изменения загрузки (не видные глазом) могут оказывать влияние на время исполения запроса, особенно при коллективной работе!

II. Влияние ПО
II.1 — разделим время прохождения запроса на клиента 1С, сервер 1С, субд
II.1.а — клиент 1С, если речь идет о клиентских компьютерах, то даже железо у всех разное (смотрите пункты выше), и уж молчу про зоопарк антивирусов, файрволлов и другого софта, который замедляет вцелом компьютер клиента 1С.
II.1.б.1 — сервер 1С состоит из нескольких рабочих процессов, где может исполняться запрос, а если он использует управляемые блокировки, то менеджер кластера.
Выходит, что если запрос окажется в разных процессах, то это уже может быть фактором различного поведения, ведь используются разные ядра, возможен разный захват памяти (в одном процессе уже данные ранее кэшировались, а вдругом нет)
II.1.б.2 — не выполняется тестирование и исправление средствами платформы, нне пересчитываются итоги регламентом
II.1.в — рсервер субд вообще обладает столькими переменными факторами, что в этой заметке мне не уложиться по объему, выделю лишь самые сильные:
II.1.в.1 — наличие эффективных индексы, которые могут быть (удалены, даже не без участия админа, например в результате рестукторизации данных в 1С или другим неявным образом без уведомления)
II.1.в.2 — дефрагментация индексов (со временем бывает так, что нужно руками перестраивать индекс заново)
II.1.в.3 — устаревшая статистика (так же принудительно обновлять бывает нужно)
II.1.в.4 — изменились условия исполнения запроса (индексы, статистика), а скомпилированный запрос устарел, и требуется сбросить процедурный кэш
II.1.в.5 — блокировки тоже очень сильно непредсказуемо замедляют запрос, тут простого решения нет, нужно исследовать причины

II.2 — кроме того, существуют настройки операционной системы, которые со временем могут быть изменены (приоритет процессоров, памяти, DEP), но не учитывать админами
II.3 — антивирусы и прочее «зло» даже не буду расшифроваывать, они влияют плохо предсказуемо
II.4 — а еще программисты меняют код конфигурации «чуть-чуть», как им кажется, а потом это проявляется самым неожыданным образом, ведь может быть изменено даже не сколько хранение данных, сколько вызов блокировок. Например конструкция в обработке проведения Документ.Дата > Дата запрета с большой вероятностью вызывает блокировку на чтение в неявном виде.
II.5 — дефрагментация данных на жестком диске

III. Объем данных
III.1 — Почему то многие забывают о том, что чем больше данных, тем больше вероятность снижения скорости запроса, ведь железо то тоже, а физически выполнить нужно больше операций
III.2 — Еще скажу просто «свертка данных», оставляя копию со старыми данными на чтение.
III.3 — Впиваются неадекватные данные, например рано или поздно найдется пользователь, который забъет документ «очень будущей датой», в результате при использовании расчета итогов производительность начинает резко просидать.

IV. Оценка производительности «на глазок» или «по незнанию»
IV.1 Если мы делаем замер отладчиком, который поидее должен все правильно показывать, имейте ввиду что он показывает фактическое время, но оно не обязательно будет стабильно повторяться при повторном замере! Хорошо, если замер будет отладчиком, а не пользователь на глазок будет включать секундомер, и выклычать, тут больше значение будет человеческая реакция нажатия кнопки 🙂
IV.2 Далеко не каждый программист обучался делать нагрузочные тесты. Откуда ему знать, что время ожидания на блокировках может быть разным (я не только про то что в конфигураторе можно настроить разный интервал ожидания), а о том, что субд в каждый конкретный раз заранее точно не может учесть все факторы, и выполняет запрос каждый раз с какой то разной скоростью. Т.е. вряд ли программист перед замером будет обновлять индекс, пересчитывать статистику, сбрасывать кэш, выгонять всех пользователей или делать замер монопольно. Некоторые замеры нельзя делать на копии, когда важно учитвтаь влияние коллективных действий пользователей, блокирующих конкурентные ресурсы.

КОРОЧЕ, ВСЕ ПРОСТО И СЛОЖНО ОДНОВРЕМЕННО!

Задачи ускорения запросов решаются, но
НЕ НАДО ДЛЯ СЛОЖНЫХ СЛУЧАЕВ ПЫТАТЬСЯ НАЙТИ ПРОСТЫЕ РЕШЕНИЯ
и
ДЛЯ ПРОСТЫХ ЗАДАЧ ИСКАТЬ НЕДОКУМЕНТИРОВАННЫЕ СЛОЖНЫЕ ТАНЦЫ С БУБНОМ.

Либо повышайте свою квалификацию, ЛИБО ПЛАТИТЕ ДЕНЬГИ КВАЛИФИЦИРОВАННЫМ СПЕЦИАЛИСТАМ, КОТОРЫЕ ЭТИМ ЗАРАБАТЫВАЮТ НА ХЛЕБ!