Рекомендации по использованию Revit Server в сетях с высокой задержкой

Введение

Revit Server предназначен для совместной работы пользователей, которые находятся относительно недалеко друг от друга, с задержкой (пингом) не более 100 миллисекунд. Обычно это ограничивает его использование проектами, расположенными в одном городе, в крайнем случае — одной стране. Однако, могут возникнуть ситуации, когда необходимо обеспечить сотрудничество между пользователям на разных континентах.

Чтобы обеспечить наилучшее взаимодействие при использовании Revit Server в сетях с высоким пингом, в этой статье рассматриваются следующие функции и рабочие процессы:

• Заимствование элементов
• Синхронизация с центральным сервером (ЦС)
• Обновление до последней версии
• Создание локальных файлов
• Обход локального сервера

Заимствование элемента

При редактировании модели пользователи должны обладать исключительным правом владения на каждый элемент, который они хотят изменить. Таким образом, Revit пытается прозрачно предоставить данное право на любой элемент, который пользователь редактирует, но которым еще не владеет. Это должно происходить практически мгновенно, чтобы избежать задержек при работе с моделью. Большинство людей воспринимают операцию, продолжительностью менее 200 миллисекунд, как «мгновенную». Таким образом, в этом рабочем процессе пользователь должен иметь возможность получить право владения на элемент менее чем за 200 мс.

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

Внутренние тесты показывают, что если задержка между Revit и ЦС превышает примерно 100 мс, разрешения на элементы не могут быть предоставлены менее чем за 200 мс. Это происходит потому, что около 90 мс используется на обработку, оставляя остальное время для передачи данных по сети. Технологии аппаратного сжатия не изменяют этот расчет, так как они только сокращают объем передаваемых данных, но не минимальное время, необходимое для доставки из одной точки в другую. В результате этот рабочий процесс не рекомендуется для пользователей с высокой задержкой подключения к ЦС. Попытки использовать его приведут к заметной задержке при заимствовании элементов, ухудшая пользовательский опыт. Вместо этого таким пользователям следует заранее брать на себя право владения элементами, либо через явное заимствование, либо проверяя рабочие наборы.

Синхронизация с центральным сервером

Когда изменения в локальной копии синхронизируются с центральной моделью, они должны быть зафиксированы на ЦС для успешного завершения операции. Процесс синхронизации у пользователей с высоким пингом (более 100 мс) займет значительно больше времени по сравнению с низким.

Чтобы уменьшить негативное влияние высокой задержки, полезно синхронизироваться с более высокой частотой, уменьшая тем самым объем передаваемых на ЦС данных. И хотя общее время, затраченное на синхронизацию в течение рабочего дня, может существенно не измениться, частые короткие задержки обычно переносятся пользователем более комфортно, чем редкие, но длительные. Также использование сжатия данных в сети может снизить объем передаваемого трафика и рекомендуется к использованию, когда это возможно.

Так как медленные операции синхронизации с ЦС могут приводить к длительным периодам блокировки центральной модели, пользователи с высоким пингом подключения могут косвенно вызывать задержки для пользователей с низким пингом. Чтобы уменьшить это влияние, рекомендуется установить настольный клиент Bluestreak и плагин Bluestreak для Revit. Эти два компонента добавят систему всплывающих уведомлений, информирующих пользователей о недоступности центральной модели из-за активности синхронизации. Таким образом, пользователи смогут планировать доступ к центральному файлу, синхронизируясь только тогда, когда ЦС свободен, что минимизирует эффекты более длительных и частых блокировок.

Обновление до последней версии

Пользователи с высоким пингом могут столкнуться с непредсказуемой производительностью при обновлении до последней версии (Reload Latest). Если кэш локального сервера актуален, процесс перезагрузки будет очень быстрым. Однако, если кэш устарел, данные модели придется загружать с ЦС, что может сильно замедлить процесс обновления.

Чтобы повысить вероятность того, что кэш останется актуальным, рекомендуется обеспечить достаточную пропускную способность между каждым локальным и ЦС, а также использовать сжатие сетевого трафика для уменьшения объема передаваемых данных. Также рекомендуется периодически очищать кэши моделей, которые больше не используются, удаляя соответствующие папки из каталога. Это уменьшит нагрузку на службу автосинхронизации локального сервера, освобождая ресурсы для моделей, которые все еще находятся в работе.

Создание локальных файлов

Когда пользователь создает новую локальную копию модели, данные о правах модели должны быть загружены с ЦС. Это может занять много времени в сетях с высокой задержкой, особенно если модели большие и сложные. Рекомендуется использовать утилиту командной строки «RevitServerTool» в качестве запланированной службы для автоматического создания локальной копии в нерабочее время. Это защитит пользователей от задержек, связанных с загрузкой данных о правах с ЦС.

Обход локального сервера

Из тестов стало известно, что в некоторых случаях администраторам не обязательно устанавливать (локальный) сервер Revit на каждой локации. Вместо этого пользователи могут подключаться напрямую к ЦС. Те, кто выбирают этот подход, обычно делают это как меру экономии, осознанно принимая компромисс в производительности. Однако такая стратегия не рекомендуется для точек с высокой задержкой до ЦС, так как пользователи могут столкнуться с неизбежностью временных затрат на передачу данных. Их сознательное увеличение еще больше снизит общую продуктивность. Для точек с высокой задержкой рекомендуется использовать отдельный локальный сервер, предпочтительно с применением технологий сжатия сетевого трафика.

Заключение

При развертывании Revit Server через WAN с задержкой свыше 100 мс каждому хосту с критическим пингом следует предоставить собственный локальный сервер, подключенный к ЦС через высокоскоростное соединение. Также настоятельно рекомендуется использовать аппаратное сжатие сетевого трафика для снижения объема данных, передаваемых по потенциально медленной сети. Хотя степень этого сжатия может варьироваться, опытным путем установлено, что любая компрессия имеет ценность, особенно в условиях медленных сетей.

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

В заключение пользователям, работающим на рабочих станциях с высокой задержкой, рекомендуется использовать рабочие наборы или явное заимствование перед началом любых манипуляций с моделью, а также синхронизировать свои изменения с центральным файлом чаще, чем это делается при привычной работе в более быстрых сетях.