> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1unic.com/odatav4/llms.txt
> Use this file to discover all available pages before exploring further.

# Производительность и память

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

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

Сервис строит описание данных (модель EDM) не целиком, а по мере обращений:

* **Первый запрос сеанса** строит только индекс «имя набора → объект метаданных». Служебный документ строится по
  этому индексу.
* **Описание набора** строится при первом обращении к нему и остаётся в памяти сеанса. Навигации и `$expand`
  достраивают нужные наборы.
* **`$metadata`** строится во временной полной копии, после чего в сеансе остаётся только готовый документ.

Первый запрос к одному набору в новом сеансе выполняется примерно в 10 раз быстрее, чем при полной сборке модели, и
занимает в памяти около 2,5 % полной модели.

## Кэш `$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, одним ответом | OData4, страницами по 1000 | `standard.odata` |
| - | -: | -: | -: |
| Справочник, 100 тыс. (154 МБ) | 11,2 с | 12–20 с | 10,7 с |
| Записи регистра накопления, 1,09 млн | **134 с** | 493 с | 147 с |
| Записи регистра бухгалтерии, 1,12 млн | 199 с | 636 с | 124 с |
| Документы с табличными частями, 100 тыс. (3,5 ГБ) | 229 с | **161–199 с** | 257–263 с |

Цифры по отдельным запросам:

| Запрос | OData4 | `standard.odata` |
| - | -: | -: |
| Справочник, `$top=1` | 28 мс | 14 мс |
| `Turnovers()` регистра накопления | 18 мс | 19 мс |
| `Balance()` регистра бухгалтерии | 230 мс | 196 мс |
| Документы, `$filter` (страница) | 221 мс | 182 мс |
| `$metadata` XML, тёплый | 28 мс | 402 мс |

Ответ OData4 компактнее. Например, записи регистра накопления занимают 1,5 ГБ против 3,3 ГБ у `standard.odata`.
Пик памяти Apache при ответах «одним ответом» на 1,5–3,5 ГБ — 1,4–1,7 ГБ: тело ответа не держится в памяти процесса
целиком.

<Info>
  Многостраничный обход больших регистров дороже из-за стоимости каждой страницы, около 0,45 с на запрос с
  продолжением. Выход — режим «Одним ответом» или страницы крупнее: `Prefer: odata.maxpagesize=5000` дал 145 с
  против 147 с у `standard.odata`.
</Info>

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

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

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

Пик памяти при построении `$metadata` на большой конфигурации — ориентировочно 180–300 МБ. Веб-модуль 1С не
возвращает память операционной системе до завершения рабочего процесса. Сеанс живёт до 20 секунд простоя, а процесс
`httpd`/`w3wp` остаётся, поэтому при большом пуле сеансов и частых `$metadata` в новых сеансах процесс может расти.

Рекомендации:

* держите `poolSize` в `default.vrd` соразмерным числу одновременных клиентов;
* оставьте `reuseSessions="autouse"`, чтобы запросы попадали в уже построенный сеанс;
* не публикуйте лишние объекты: [состав](/odatav4/admin/composition) задаёт размер индекса и `$metadata`;
* перезапускайте рабочий процесс веб-сервера по расписанию или по достижении предела памяти.

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

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.