Диагностика и повышение производительности AllegroClient и 1С

Содержание

1. От чего зависит скорость работы AllegroClient

Пример 1
Пример 2

2. Основные причины снижения производительности
3. Быстрая проверка сервера

Процессор
Оперативная память
Дисковая подсистема
Сетевое соединение
Размер HTTP-запросов и ответов
Сервер 1С

Блокировки
Регламентные задания 1С
Обслуживание информационной базы
Размер информационной базы

Свертка и архивирование
Физическое уменьшение файла базы

Microsoft SQL Server
PostgreSQL
Индексы
Статистика СУБД
Поиск неоптимальных запросов

Что искать в запросах

Что делать после обнаружения проблемы
Краткий чек-лист

1. От чего зависит скорость работы AllegroClient

AllegroClient взаимодействует с 1С через HTTP-сервисы.

Поэтому время выполнения операции зависит не только от мобильного устройства, но и от всей цепочки:

Мобильное устройство;
Мобильная сеть / Wi-Fi;
Интернет / локальная сеть;
HTTP-сервис;
Сервер 1С;
Код 1С и запросы;
СУБД;
CPU / RAM / дисковая подсистема.

Если AllegroClient выполняет операцию медленно, необходимо определить, на каком участке возникает задержка.

Главная задача первого этапа — определить, где находится основная часть времени: в сети, HTTP, коде 1С или СУБД.

Технологический журнал используется для определения времени работы с СУБД и поиска конкретных запросов, которые могут быть причиной задержки.

Пример 1

СУБД: 0,2 сек

1С: 2,5 сек

AllegroClient: 3,0 сек

В этом случае СУБД работает быстро, а основное время обработки приходится на код 1С.

Пример 2

1С: 0,3 сек

AllegroClient: 8,0 сек

В этом случае основное время уходит до или после обработки запроса на сервере 1С.

Необходимо искать проблему в сети, HTTP-соединении, объеме передаваемых данных или обработке ответа мобильным приложением.

Время работы с СУБД напрямую из AllegroClient не измеряется.

Его определяют на стороне 1С с помощью технологического журнала, который позволяет увидеть длительность операций работы с СУБД и конкретные SQL-запросы.

• Время работы с СУБД

• Время обработки запроса на сервере 1С

• Время выполнения операции AllegroClient

2. Основные причины снижения производительности

высокая загрузка процессора;
недостаток оперативной памяти;
высокая нагрузка на диски;
медленная дисковая подсистема;
проблемы с сетью;
большое количество данных в информационной базе;
отсутствие или неправильная настройка регламентных работ;
устаревшая статистика СУБД;
проблемы с индексами;
блокировки;
неоптимальные запросы;
изменение плана выполнения запроса;
длительные фоновые и регламентные задания;
резервное копирование во время интенсивной работы;
накопление большого количества исторических данных.

3. Быстрая проверка сервера

Первоначально рекомендуется проверить четыре основных показателя:

Показатель	Ориентир	Требует внимания
CPU	до 70%	длительно >80–90%
Свободная RAM	более 20%	менее 10%
Очередь диска	до 2	длительно >2
Свободное место	более 15–20%	менее 10%

Значения являются ориентирами, а не жесткими требованиями.

Важны продолжительность нагрузки и связь с моментом возникновения проблемы.

Кратковременный скачок CPU или очереди диска не является сам по себе причиной для вмешательства.

Процессор

Проверить загрузку CPU можно стандартными средствами операционной системы (Диспетчер задач → Производительность → ЦП).

Оперативная память

Проверить:

общий объем RAM;
доступную память;
использование файла подкачки.

Ориентир:

Свободно >20% — нормально

10–20% — обратить внимание

<10% — необходимо исследование

Особенно неблагоприятна ситуация, когда недостаток RAM приводит к активному использованию файла подкачки. В этом случае резко увеличивается нагрузка на диски.

Дисковая подсистема

Для работы 1С и СУБД скорость дисков имеет большое значение.

В первую очередь проверяются:

Загрузка диска

до 70% — обычно нормально

70–90% — обратить внимание

>90% — необходимо исследовать

Очередь диска

до 2 — обычно нормально

2–5 — обратить внимание

>5 — возможная проблема

Время отклика диска

Ориентировочно:

до 10 мс — хорошо

10–20 мс — допустимо

20–30 мс — обратить внимание

>30 мс — возможная проблема

Для SSD и NVMe постоянно высокое время отклика требует отдельного исследования.

Сетевое соединение

Для AllegroClient необходимо отдельно проверять сеть между мобильным устройством и сервером.

Проверяются:

стабильность соединения;
время отклика;
потери пакетов;
скачки задержки;
скорость передачи данных.

Для локальной сети нормальная ситуация:

Потери пакетов = 0%

При мобильном Интернете абсолютное значение ping менее показательно. Важнее стабильность соединения и отсутствие резких скачков задержки.

Размер HTTP-запросов и ответов

Если HTTP-сервис возвращает большое количество данных, скорость работы может снижаться даже при нормальной работе 1С.

Для операций AllegroClient желательно контролировать:

размер HTTP-запроса;
размер HTTP-ответа;
количество передаваемых записей;
время сериализации данных;
время обработки ответа мобильным приложением.

Например, если пользователю требуется 20 товаров, но HTTP-сервис возвращает несколько тысяч записей, проблема может быть не в СУБД, а в организации обмена данными.

Сервер 1С

Если сеть работает нормально, необходимо проверить сервер 1С.

Основной инструмент для детального анализа — технологический журнал 1С.

С его помощью можно определить:

длительность выполнения операций;
время работы с СУБД;
SQL-запросы;
ошибки;
блокировки;
длительные операции.

Это позволяет перейти от предположения:

«1С работает медленно» к конкретной причине: «Данная операция большую часть времени ожидает выполнения SQL-запроса».

Блокировки

Блокировки — одна из причин, которую легко пропустить.

Запрос может быть сам по себе быстрым, но долго ждать освобождения данных.

Например:

Выполнение запроса 100 мс

Ожидание блокировки 8 сек

Общее время 8,1 сек

Для пользователя AllegroClient это будет выглядеть как медленная операция.

Если производительность нестабильна — одна и та же операция то выполняется быстро, то занимает несколько секунд — необходимо проверить блокировки и длительные транзакции.

Регламентные задания 1С

Необходимо проверить:

выполняются ли регламентные задания;
нет ли заданий с ошибками;
не выполняется ли какое-либо задание слишком долго;
не создают ли фоновые задания значительную нагрузку.

Особое внимание:

обменам;
массовым обработкам;
расчетам;
резервному копированию;
обслуживанию информационной базы.

Также необходимо сопоставлять время возникновения проблем с расписанием регламентных заданий.

Обслуживание информационной базы

Необходимо регулярно контролировать состояние информационной базы.

В зависимости от конфигурации и используемых механизмов проверяются:

состояние итогов;
необходимость пересчета итогов;
регламентные операции;
накопление служебных данных;
рост объема базы.

Если предусмотрен пересчет итогов, необходимо контролировать его выполнение и актуальность.

Размер информационной базы

По мере эксплуатации базы увеличиваются:

таблицы;
регистры;
документы;
движения;
индексы;
объем исторических данных.

Большой объем данных может увеличивать время выполнения запросов и обслуживания СУБД.

Поэтому необходимо периодически анализировать:

общий размер базы;
темп роста;
наиболее крупные таблицы;
наиболее крупные регистры;
объем исторических данных.

Свертка и архивирование

Если в базе накопилось большое количество старых данных, необходимо рассмотреть возможность:

архивирования;
удаления ненужных данных;
свертки информационной базы;
сокращения периода хранения оперативных данных.

Уменьшение объема рабочей базы может положительно повлиять на производительность, особенно если запросы работают с большими таблицами.

Дополнительный эффект может возникнуть за счет уменьшения объема индексов и улучшения использования оперативной памяти СУБД.

Физическое уменьшение файла базы

Необходимо различать: уменьшение количества данных и уменьшение физического файла базы.

Например, после удаления старых данных SQL Server может иметь:

Файл базы: 100 GB

Фактические данные: 60 GB

Свободное место: 40 GB

Само по себе наличие свободного места внутри файла не является проблемой.

Microsoft SQL Server

Необходимо проверить наличие автоматического обслуживания базы.

SQL Server Agent.

В: SQL Server Management Studio → SQL Server Agent → Jobs

проверить наличие заданий, связанных с:

резервным копированием;
проверкой целостности;
обслуживанием индексов;
обновлением статистики.

Для каждого задания необходимо проверить:

когда запускалось последний раз;
успешно ли завершилось;
есть ли ошибки;
когда запланирован следующий запуск.

Если SQL Server Agent не работает или необходимые задания отсутствуют, автоматическое обслуживание может не выполняться.

PostgreSQL

Для PostgreSQL важнейшую роль играет автоматическое обслуживание.

Необходимо проверить:

включен ли autovacuum;
выполняется ли VACUUM;
выполняется ли ANALYZE;
когда таблицы обслуживались последний раз;
нет ли значительного накопления удаленных строк.

Наличие: autovacuum = on

само по себе еще не гарантирует, что обслуживание происходит эффективно. Необходимо проверить фактическое состояние базы.

Индексы

Индексы ускоряют поиск данных, но сами требуют места и обслуживания.

Необходимо проверять:

наличие необходимых индексов;
состояние крупных индексов;
фрагментацию в SQL Server;
использование индексов;
наличие проблем с индексами PostgreSQL.

Не следует выполнять:

REBUILD всех индексов

или

REINDEX всей базы

без причины.

Сначала необходимо определить, что именно вызывает проблему.

Статистика СУБД

СУБД использует статистику для выбора плана выполнения запроса.

Если статистика устарела, СУБД может выбрать неоптимальный план.

Признаки возможной проблемы:

Запрос раньше выполнялся быстро

↓

данные значительно изменились

↓

запрос стал медленным

↓

план выполнения изменился

В этом случае необходимо проверить актуальность статистики.

Для SQL Server проверяется автоматическое обновление статистики.

Для PostgreSQL — работа ANALYZE и autovacuum.

Поиск неоптимальных запросов

Если сервер, память, диски и сеть работают нормально, необходимо переходить к анализу запросов.

1С

Использовать:

технологический журнал;
средства анализа производительности;
информацию о времени работы с СУБД.

Microsoft SQL Server

Использовать:

Query Store;
планы выполнения;
DMVs.

PostgreSQL

Использовать:

pg_stat_statements;
EXPLAIN;
EXPLAIN ANALYZE.

Что искать в запросах

Типичные проблемы:

Слишком большой объем данных

Запросу требуется 20 строк

↓

из базы читаются миллионы строк

Отсутствие подходящего индекса

СУБД вынуждена просматривать большое количество данных вместо быстрого поиска.

Запрос внутри цикла

1000 товаров

↓

1000 отдельных запросов

вместо одного пакетного запроса.

Неправильный план выполнения

СУБД выбирает способ выполнения, который оказался неэффективным для текущего объема и распределения данных.

Устаревшая статистика

Оптимизатор неправильно оценивает количество строк и выбирает неподходящий план.

Что делать после обнаружения проблемы

Каждое изменение необходимо подтверждать повторным измерением.

Например:

Было:

запрос = 5,2 сек

Изменили индекс

Стало:

запрос = 0,8 сек

или:

Было:

операция AllegroClient = 7,5 сек

Обновили статистику

Стало:

операция = 1,2 сек

Если улучшения нет, необходимо вернуться к диагностике и проверить следующую возможную причину.

Краткий чек-лист

Сервер

CPU не загружен постоянно более чем на 80–90%
свободно более 20% RAM
нет активного использования файла подкачки
очередь диска обычно не более 2
время отклика диска не повышено
достаточно свободного места

Сеть

нет потерь пакетов
стабильное время отклика
нет резких скачков задержки
размер HTTP-ответов соответствует необходимому объему данных

1С

регламентные задания выполняются
нет длительных заданий с ошибками
проверено состояние итогов
проверены блокировки
проверен технологический журнал

Информационная база

контролируется размер базы
контролируется рост базы
анализируются крупные таблицы и регистры
проводится архивирование при необходимости
рассматривается свертка старых данных

SQL Server

работает SQL Server Agent
настроены Jobs обслуживания
выполняется Backup
выполняется проверка целостности
актуальна статистика
проверяется состояние индексов
используется Query Store

PostgreSQL

включен autovacuum
выполняется VACUUM
выполняется ANALYZE
контролируется состояние таблиц
контролируется bloat
проверяются индексы
используется pg_stat_statements

Запросы

найден конкретный медленный запрос
проверен план выполнения
проверено количество обрабатываемых строк
проверены индексы
проверена статистика
проверены блокировки

Главный принцип

Сначала измерить — затем определить причину — затем выполнить исправление — затем снова измерить.

Перестройка индексов, обновление статистики, VACUUM, свертка базы и другие операции обслуживания являются инструментами устранения конкретных проблем, а не универсальным способом ускорения 1С.

Для AllegroClient особенно важно начинать диагностику с фактического времени конкретной операции и разделения этого времени на сеть, 1С и СУБД. Это позволяет быстро определить направление поиска и не тратить время на обслуживание тех компонентов, которые работают нормально.

Остались вопросы?

Оставьте свои данные и мы свяжемся с Вами