На встрече 23 июля Алексей Тимофеев (архитектор системы) начал с самой распространенной проблемы с которой многие столкнулись: ошибка APLM0012.
Данная ошибка возникает при запросе историй изменений по сертификатам в первую очередь и по записям журнала. Возникает она в связи с пусковым периодом и с той интенсивностью которая есть от клиентов шлюза.
Рекомендации:
- Оптимизация существующих операций получения списков
- Выделение отдельной очереди для “тяжелых” запросов
- Новый функционал загрузки истории изменений
То есть уменьшение интенсивности запроса, запрашивать истории изменений ровно тогда когда это необходимо.
Настройка параметра запроса, в первую очередь — запрашиваемый период. Сегодня встречаются запросы за неделю, месяц, за год и т.д.
По мнению Алексея, оптимальное значение периода- это запрос за сутки, не более. Запрос создан для того, чтобы смотреть историю последних изменений. Для актуальных сведений по ЭВСД за какой- то период — для этого есть отдельная операция получение списка, где вы можете установить фильтр по дате создания этого документа, и получить документы для построения аналитики, статистики и т.д.
Следующий момент- определение страниц. Размер страниц сейчас ограничен 1000 записями. Это зависит от характеристик каждого предприятия, от общего объема документов, которые содержатся в базе, от интенсивности оформления, которые существуют для каждой определенной площадки.
Рекомендации: эмпирически подбирать это значение.
То есть в зависимости от объема документа, от количества документа, сейчас во время пускового периода рекомендуется начать со страницы размером 500 записей и далее подбирать для своего предприятия, то значение которое вас устраивает.
4. пункт- Очень часто запрашиваются все списки, всех документов независимо от потребностей.
Рекомендации: В операции предусмотрены набор фильтров. Если вы конкретизируете для каждого запроса что хотите получить, то запрос будет эффективнее по времени обработки документов, и по размеру передаваемых данных. То же самое и по статусу данных.
Общая рекомендация: тонко настраивать по каждому конкретному случаю.
Сейчас разрабатывается механизм который обеспечит стабильную работу остальных операций путём вынесения в отдельную дополнительную очередь запросов тяжелых на историю получения изменений. Тестируют несколько вариантов доп. операций, функционал по получению историй изменений, в том числе до возможного варианта истории загрузки в виде архива. Как будет готово представят бизнес-сообществу чтобы улучшить работу в истории загрузки изменений в работе со шлюзом.
Вопрос не количества запросов- вопрос характера профиля нагрузки и алгоритма который используют.
Основные моменты, которые вызывают беспокойство:
- Опрос истории изменений каждую минуту / 5 минут.
То есть история запросов каждую минуту происходит по одной площадке. Для чего не понятно с учетом того, что любой запрос который приводит к изменению в системе — возвращает актуальные сведения, которые можно сохранить.
О том, как эти же ошибки решает ЗАО АСП рассказал в своем интервью Сергей Барышев ген. директор.
Чтобы уменьшить нагрузку и повысить производительность (проблема APLM0012) с учетом того, что ориентированы на большие объемы данных и на большое количество ЭВСД мы делаем очередь заявок и очередь ответов, при этом распределяем приоритеты по каждой заявке. Таким образом система формирует изначально эти очереди. А что делать когда возникает ошибка APLM0012 при условии, что некорректно заполнен сам сертификат? Смотрите ответы на эти и другие вопросы в видео.
В первую очередь: нужно использовать те актуальные сведения, которые возвращаются в ответе операции. Выполнили гашение, пришел погашенный сертификат и все остальные- сохраните и синхронизируйте информацию без нового запроса. А не делать запрос снова.
2. Подбор записи журнала перед отгрузкой
3. Неравномерный поток запросов- надо выполнять сглаживание трафика.
4. Интенсивный опрос результата обработки заявок. -Определить в системах тайм-аут (задержку) между последующими обращениями к сервису к каждой корректной операции.
5.Запрос результата по “старым” заявкам. -Шлюз хранит в системе определенный период заявок- 3 суток. Заявки старше 3-х дней переносятся в архив и недоступны для получения.- однако большой поток запросов на получение заявок свыше 3-х суток.
6. Повторное получение результата заявки.Наблюдают повторное получение результата. Зачем? проверьте мониторинг у себя.
7. Загрузка реестров с offsetOutOfRange- просьба следить за своим мониторингом.
8. Злоупотребление объединением и инвентаризацией.
9. Отсутствие обработки системных ошибок.
10. Отсутствие реакции на бизнес-ошибки. Если свыше 10% от числа общих операций, то это повод задуматься. Для ряда пользователей шлюза превышает 70- 80%. Настраивать необходимо мониторинг у себя. Это не пользовательский запрос, операция выполняется в автоматическом режиме и система на нее никаким образом не реагирует.
11. Интеграция “через веб”- попытка интегрироваться через веб интерфейс. Веб интерфейс предназначен для работы пользователей, для автоматизированных есть шлюз. Веб- интерфейс не использовать не по назначению.
В своих системах предусматривать подсказки уберегающие пользователей от действий: например, ошибочное гашение. Количество систем которые будут интегрированы в финале с Меркурием и достигнет примерно сотни тысяч систем в не отдаленном будущем. Поэтому все разработчики представляйте свои решения. Резюмировал выступление Алексея Тимофеева Николай Власов.
