Skip to main content

​
Ленивая модель

Сервис строит описание данных (модель EDM) не целиком, а по мере обращений:
  • Первый запрос сеанса строит только индекс «имя набора → объект метаданных». Служебный документ строится по этому индексу.
  • Описание набора строится при первом обращении к нему и остаётся в памяти сеанса. Навигации и $expand достраивают нужные наборы.
  • $metadata строится во временной полной копии, после чего в сеансе остаётся только готовый документ.
Первый запрос к одному набору в новом сеансе выполняется примерно в 10 раз быстрее, чем при полной сборке модели, и занимает в памяти около 2,5 % полной модели.

​
Кэш $metadata между сеансами

Флажок **«Хранить metadataмеждусеансами»∗∗навкладке«Движки»включёнпоумолчанию.Готовыедокументы‘metadata между сеансами»** на вкладке «Движки» включён по умолчанию. Готовые документы `metadata` хранятся в базе по ключу, в который входят:
  • состав публикации;
  • настройки;
  • профиль;
  • набор доступных пользователю объектов;
  • отпечаток среды: платформа, конфигурация, расширения.
Первый $metadata нового сеанса строится за ~0,55 с вместо ~2,7 с. Проверка изменений конфигурации:
  • Полная (по умолчанию) обходит метаданные (около 0,3 с на новый сеанс) и замечает любое изменение.
  • По номеру версии быстрее, но изменение конфигурации без смены номера версии сервис увидит только после перезапуска веб-сервера или сброса кэша: снимите и снова поставьте флажок кэша.

​
Страницы или одним ответом

Настройка «Выдача коллекций» (вкладка «Движки»):
  • Страницами (по умолчанию) — по 1000 строк со ссылкой @odata.nextLink на продолжение, как требует OData v4.
  • Одним ответом — весь результат в одном ответе, как у standard.odata. Сервер читает набор порциями (размер порции — 5000 строк по умолчанию, для широких строк меньше) и пишет их в поток ответа.
Страницами сервис отвечает всегда, если:
  • клиент прислал Prefer: odata.maxpagesize;
  • запрос продолжает выдачу по $skiptoken;
  • это операция $batch;
  • у профиля задан лимит страницы.
Настройка «Наибольшее число строк одним ответом» защищает от случайной выгрузки десятков миллионов строк: дальше этого предела ответ заканчивается ссылкой на продолжение. 0 — без предела.

​
Замеры

База со 100 тыс. документов (1 млн строк табличной части), 100 тыс. элементов справочника и около 1 млн записей в каждом регистре. Файловая база, веб-сервер Apache на той же машине, выдача JSON — компонентой. Цифры по отдельным запросам: Ответ OData4 компактнее. Например, записи регистра накопления занимают 1,5 ГБ против 3,3 ГБ у standard.odata. Пик памяти Apache при ответах «одним ответом» на 1,5–3,5 ГБ — 1,4–1,7 ГБ: тело ответа не держится в памяти процесса целиком.
Многостраничный обход больших регистров дороже из-за стоимости каждой страницы, около 0,45 с на запрос с продолжением. Выход — режим «Одним ответом» или страницы крупнее: Prefer: odata.maxpagesize=5000 дал 145 с против 147 с у standard.odata.

​
Советы клиентам

  • Выбирайте только нужные поля через $select. Документы с тремя полями отдаются в десятки раз быстрее, чем целиком с табличными частями.
  • Фильтруйте на сервере через $filter, а не после загрузки.
  • Укрупняйте страницы заголовком Prefer: odata.maxpagesize=5000, если клиент обходит много страниц.
  • Не раскрывайте лишнего: $expand=* на документе может дать сотни соединений в запросе. Число раскрытий ограничено лимитами.
  • Агрегируйте на сервере через $apply и виртуальные таблицы, а не выгрузкой всех записей.

​
Память рабочего процесса веб-сервера

Пик памяти при построении $metadata на большой конфигурации — ориентировочно 180–300 МБ. Веб-модуль 1С не возвращает память операционной системе до завершения рабочего процесса. Сеанс живёт до 20 секунд простоя, а процесс httpd/w3wp остаётся, поэтому при большом пуле сеансов и частых $metadata в новых сеансах процесс может расти. Рекомендации:
  • держите poolSize в default.vrd соразмерным числу одновременных клиентов;
  • оставьте reuseSessions="autouse", чтобы запросы попадали в уже построенный сеанс;
  • не публикуйте лишние объекты: состав задаёт размер индекса и $metadata;
  • перезапускайте рабочий процесс веб-сервера по расписанию или по достижении предела памяти.

​
Журнал и блокировки

Журнал запросов пишется короткими транзакциями по собственному ключу и в клиент-серверной базе не задерживает ответ. В файловой базе блокировки табличные, поэтому при плотном потоке и включённом журнале ответ может ждать тайм-аута блокировки (до 20 с). Для нагруженной работы используйте клиент-серверную базу или уровень журнала «Ошибки».