Серверу следует (SHOULD) передавать новое куки достаточно часто, чтобы избежать передачи уже предоставленной клиенту информации. Даже когда изменения DIT не приводят к передаче сведений по синхронизации содержимого каталога, может быть полезно предоставить новое куки с помощью сообщения Sync Info Message. Однако серверу следует (SHOULD) избегать перегрузки клиента или сети сообщениями Sync Info Message.
Во время стадии непрерывного обслуживания серверу следует (SHOULD) объединять несколько исходящих сообщений с изменениями одной и той же записи. Сервер может (MAY) задержать генерацию сообщения об обновлении записи в ожидании последующих изменений той же записи, которые можно будет объединить. Длительность задержки должна быть достаточно большой, чтобы объединить запросы на обновления, следующие один за другим, но и не слишком большой, чтобы временные расхождения, вызванные такой задержкой, своевременно корректировались.
Для уменьшения количества трафика синхронизации серверу следует (SHOULD) использовать сообщения Sync Info Message с syncIdSet при наличии нескольких сообщений удаления или наличия.
Также имейте ввиду, что может быть много клиентов, заинтересованных в получении какого-либо конкретного изменения каталога, и попытка сервера обслужить сразу всех таких клиентов может вызвать перегрузку в сети. Вопросы перегрузки становятся ещё более острыми, когда изменение требует передачи большого объёма данных каждому заинтересованному клиенту. Те, кто занимается разработкой, а также развёртыванием серверов, должны предпринимать шаги для предотвращения сетевых перегрузок и управления ими.
3.10. Объединение (мультиплексирование) операций
Модель протокола LDAP [RFC4511] позволяет объединять операции в рамках одной сессии LDAP. Клиентам не следует (SHOULD NOT) поддерживать несколько сессий LDAP с одним и тем же сервером. Серверам следует (SHOULD) обеспечить, чтобы ответы от одновременно обрабатываемых операций справедливо чередовались.
Клиентам следует (SHOULD) объединять операции Sync, наборы результатов которых в значительной степени перекрывают друг друга. Это позволяет избежать необходимости возвращать несколько сообщений, по одному для каждой перекрывающейся сессии, для внесения изменений в записи, попадающие в такое перекрытие.
Клиентам не следует (SHOULD NOT) объединять операции Sync, наборы результатов которых в значительной степени не перекрывают друг друга. Такой подход гарантирует, что распространение действий событий, требующих возвращения ответа e-syncRefreshRequired, можно будет ограничить на минимально возможное число наборов результатов.