мобильная разработка за неделю #639: почему кладовщик ждал приложение 8 секунд

Кладовщик ждал карточку товара 8 секунд, потому что мобильное приложение при каждом сканировании штрихкода отправляло синхронный запрос к 1С без кэша и очереди. Быстрое решение — убрать лишние обращения к базе и включить локальный кэш; долгосрочное — доработать интеграцию мобильного клиента с 1С и проверить производительность самого сервера.

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

Склад дистрибьютора стройматериалов на юге Москвы, 9:12 утра. Кладовщик сканирует накладную на приёмку — 180 позиций, у каждой свой штрихкод, срок годности и ячейка хранения. После каждого скана экран замирает на 8 секунд, крутится индикатор загрузки. За смену такие паузы складываются больше чем в час простоя, а рабочих смен в месяце двадцать две — это почти двое суток впустую за месяц на одного кладовщика.

Один скан — не проблема: приложение отвечает нормально, если кладовщик работает в одиночку, вечером, когда склад почти пустой. Но с 9 до 11 утра одновременно включены 11 терминалов, и каждый при сканировании синхронно дёргает 1С — без очереди, без кэша справочника номенклатуры. Сервер получает не 11 отдельных запросов, а всплеск нагрузки в разы больше обычного, поэтому именно в часы приёмки отклик проседает с полутора секунд до восьми и выше, а к обеду снова возвращается в норму.

Причин обычно несколько сразу, и они усиливают друг друга. Мобильное приложение написано так, что ждёт ответа от 1С синхронно — экран блокируется, пока запрос не вернётся, вместо того чтобы работать в фоне и сразу отдавать управление кладовщику. HTTP-сервис на стороне базы делает запрос без индекса по нужному регистру и фактически перебирает весь справочник остатков ради одной позиции. А сам сервер — виртуальная машина на 2 ядра и 4 ГБ памяти, которую подбирали три года назад под пять одновременных пользователей, а не под одиннадцать терминалов в пиковый час.

Похожая картина встречается не только на складе. Если мобильное приложение так же синхронно дёргает 1С у продавцов в шоуруме или у курьеров на маршруте, те же 8 секунд ожидания на каждом шаге превращаются в очередь у кассы или в сорванный тайм-слот доставки — причина везде одна: синхронный запрос без кэша и без очереди.

Если не разбираться, счёт идёт не на секунды раздражения. Просрочка отгрузки на маркетплейс по вине задержки на приёмке — это штраф по договору, и не один. Час простоя за смену — это около 12% рабочего времени кладовщика, оплаченного впустую, а на складе с заметным зарплатным фондом это ощутимая сумма каждый месяц. И проблема не стоит на месте: при найме ещё пяти-семи человек нагрузка не вырастет плавно — сервер, который еле тянул одиннадцать терминалов, встанет намертво на восемнадцати, и чинить придётся уже не оптимизацию, а аварию в разгар сезона.

почему быстрое решение не убирает тормоза насовсем 🔁

Кэш подключили, очередь настроили, отклик упал до полутора секунд — а через месяц по вторникам к 9:30 приложение снова виснет. На этот раз всплеск совпадает не со сканированием само по себе, а с ночным регламентным заданием в 1С, которое не успевает завершиться до начала смены и держит базу занятой.

В таком случае причина не в мобильном приложении и не в том же запросе, что и раньше, а в ресурсах сервера или в конфликте процессов на нём. Прежде чем менять что-то ещё вслепую, стоит формально измерить производительность базы: для этого есть тест Гилёва — стандартный способ оценить скорость 1С в условных попугаях и сравнить результат с эталонными значениями для похожей конфигурации и числа пользователей.

как читать результат теста

Если результат заметно ниже нормы для конфигурации такого масштаба, дело в ресурсах сервера или в конкурирующих процессах: резервном копировании, которое запускается в рабочее время, других базах на той же машине, антивирусе, который сканирует файлы базы прямо во время смены. Если результат в норме, а тормозит всё равно — возвращаются к конкретному обмену и смотрят логи именно мобильного приложения. Диагностику такого рода обычно делают сисадминским сопровождением по ставке от 3 800 руб/час: на локализацию конкретной причины уходит несколько часов работы, а не дни простоя склада.

что сделать, чтобы приложение не зависало на складе повторно 🛡️

Разовая починка не гарантирует, что через полгода при найме ещё нескольких кладовщиков история не повторится: то, что уверенно работало на 11 терминалах, может не выдержать 18. Четыре вещи снимают этот риск заранее.

• ✓считать мощность сервера не под текущий штат, а под штат через год: системные требования 1С дают официальный ориентир по ресурсам на число активных пользователей и помогают не покупать сервер впритык
• ✓обновлять платформу и конфигурацию 1С регулярно: старые релизы обрабатывают типовые запросы заметно медленнее новых, а обновление 1С заодно закрывает известные уязвимости, не связанные напрямую со скоростью, но тоже рано или поздно аукающиеся
• ✓проверить, не перерос ли складской учёт саму систему: если начинали с самописной конфигурации под десяток позиций, а сейчас склад отгружает тысячи заказов в месяц, есть смысл посмотреть в сторону 1С:Управления торговлей, а при нескольких складах и сложной логистике — 1С:ERP
• ✓раз в квартал прогонять нагрузочный тест на пиковое число терминалов, а не дожидаться, пока о проблеме сообщат кладовщики в разгар сезонной приёмки

Профилактика дешевле аварии: те же четыре пункта разово стоят меньше, чем один сорванный день приёмки в высокий сезон, помноженный на штрафы за просрочку.

сколько стоит поддержка мобильного приложения и интеграции с 1С 💰

Диагностика и точечные правки — кэш, очередь запросов, оптимизация HTTP-сервиса — чаще всего укладываются в сопровождение по ставке 3 800 руб/час: специалист смотрит логи обмена, находит конкретный медленный запрос и переписывает его без остановки склада на время работ. Для большинства случаев из этой статьи разговор идёт о нескольких часах, а не о неделях простоя.

Если приложение самописное и старше нескольких лет, а точечные правки уже не спасают, дешевле не латать его бесконечно, а спроектировать новый мобильный клиент под текущие процессы склада — с кэшем и асинхронной очередью в архитектуре с самого начала, а не поверх старого кода. Такая разработка с нуля стоит от 500 000 руб и включает и мобильное приложение, и обвязку интеграции с 1С.

В ukved.ru сначала разбираем логи и смотрим, где именно теряются секунды, и только потом говорим, что дешевле — доработка конкретного запроса или новое приложение. Обычно понятно в течение одного разговора, какой сценарий подходит: закрыть один медленный запрос или пересобрать мобильный клиент целиком. Часто хватает первого.

❓ Частые вопросы

Сколько времени занимает диагностика медленного мобильного приложения на 1С?

Обычно от 2 до 6 часов работы сисадмина: смотрим логи обмена, замеряем тестом Гилёва скорость базы и локализуем, где теряются секунды — в мобильном клиенте, в HTTP-сервисе или в самом сервере. Это не блокирует работу склада — диагностику проводят параллельно с обычной сменой, не останавливая приёмку.

Можно ли ускорить приложение без замены сервера?

В большинстве случаев да. Кэш справочников на устройстве, очередь запросов вместо синхронных вызовов и переписанный под индекс запрос к остаткам обычно решают проблему без апгрейда железа. Замена сервера нужна реже, чем кажется — обычно только если тест Гилёва показывает нехватку именно ресурсов.

Что делать, если после доработки приложение снова тормозит через несколько месяцев?

Значит выросла нагрузка — больше терминалов, больше позиций в накладных — либо на сервере появились конкурирующие процессы. Нужна повторная диагностика мощности, а не повторная правка того же запроса. Иногда причина в ночном регламентном задании, которое не успевает закончиться до начала смены.

Дешевле доработать старое приложение или сделать новое?

Если приложению больше 3-4 лет и точечные правки уже не помогают — разработка нового клиента от 500 000 руб окупается быстрее, чем бесконечные исправления старой архитектуры. Новое приложение сразу проектируют с кэшем и очередью запросов внутри, а не добавляют их поверх старого кода.

Подходит ли это решение для склада с 5-10 кладовщиками?

Да, диагностика и точечные правки актуальны при любом числе терминалов — чем раньше поймать проблему с синхронными запросами, тем дешевле её исправить до масштабирования. На пяти терминалах задержка в 8 секунд раздражает, но не рушит смену; на двадцати она уже срывает график отгрузок.