Вернуться к статьям План лечения может долго открываться даже при небольшой таблице на экране. Время уходит на получение истории процедур, предложений, оплаты и подписей связанных элементов CRM. Чтобы ускорить открытие, нужно измерять весь путь запроса, включая ожидание блокировок и повторные обращения за одними данными.
В сентябре мы разобрали такой сценарий в приложении клиники Ратинова. Число вызовов при сборке контекста сократилось, но итоговые замеры по-прежнему показывают большой разброс. Ниже приводим изменения и границы результата.
Что загружается за таблицей
Чтобы показать состояние ячейки, приложение сопоставляет назначенные день и зону с товарами предложений, оплатой и выполненными процедурами. Оно также читает сохранённые связи между ними. История может включать десятки записей.
Если получать каждую часть последовательно, задержки складываются. Дополнительное ожидание возникает, когда чтение долго удерживает блокировку, а пользователь открывает ту же карточку в соседней вкладке.
Какие обращения удалось сократить
Мы убрали повторное получение товарных единиц при сборке одного ответа. Подписи связанных элементов теперь загружаются по необходимости, а история процедур читается пакетами через штатный механизм batch.
На проверенном наборе данных сборка контекста потребовала 11 вызовов вместо прежних 59 при первом чтении. Отдельно выполнялась проверка личности пользователя. Внутри пакетного обращения оставались 49 команд по процедурам: уменьшение числа внешних вызовов не означает исчезновение всей работы на стороне CRM.
Почему пришлось изменить блокировки
Длительное чтение не должно удерживать блокировку всё время, пока приложение ожидает ответы внешней системы. Мы сократили защищённый участок чтения и добавили кратковременное повторное использование загруженной истории.
Одновременные чтения одной карточки одним пользователем могут использовать общий выполняющийся запрос. В проверке с двумя вкладками подтвердилось, что повторная сборка не запускалась независимо. Этот результат получен в одном процессе приложения; он не подтверждает такое же объединение между несколькими процессами.
Проверки при записи выполнения остались отдельными. Ускорение чтения не должно разрешать повторное проведение одной оплаченной единицы.
Что показали замеры 28 сентября
После последнего обновления измерили пять ответов API на рабочей карточке:
| Сценарий | Время ответа |
|---|---|
| Первое чтение | 35,609 с |
| Повторное чтение | 44,468 с |
| Другое первое чтение | 6,478 с |
| Две вкладки, первый запрос | 20,268 с |
| Две вкладки, второй запрос | 20,129 с |
Это длительность ответа API, а не полное время до готовности интерфейса в браузере. Небольшая серия не даёт статистики для всех пациентов и часов работы клиники. Повторное чтение в одном из замеров оказалось медленнее первого, поэтому обещать стабильное открытие за несколько секунд по этим данным нельзя.
Что считать результатом
Подтверждены сокращение внешних вызовов, пакетное чтение истории и объединение совпадающих запросов в проверенном сценарии. Разброс общей задержки остаётся задачей для дальнейших измерений.
При похожей проблеме полезно отдельно измерить получение плана, историю, связанные документы и ожидание блокировок. После каждого изменения нужно повторить одинаковые сценарии и проверить корректность назначений. В этой проверке процедуры не проводили; проверяли загрузку и сохранность распределения.
Такой разбор помогает выбрать следующий шаг по фактическому источнику задержки. Устройство самого приложения и рабочие роли описаны в кейсе клиники Ратинова.