Network Profiler
Mirror Profiler является частью подписки Mirror Pro. На момент написания этой статьи он доступен для наших Спонсоров на GitHub.
Установка
Убедитесь, что у вас установлена последняя версия Mirror.
Станьте спонспором на GitHub если вы этого еще не сделали.
Посетите Mirror Networking Discord. В канале информации вы узнаете, как присоединиться к каналу github_sponsors.
В канале github_sponsors закрепленные сообщения подскажут вам, как загрузить профилировщик.
Установите пакет unity в свой проект.
Использование
В меню Unity, кликните на Open Window -> Analysis -> Mirror Network Profiler. Появится окно profiler
Вы можете закрепить profiler в любом месте, где захотите
Запустите свою игру в редакторе
Нажмите "Record" в profiler'e
Начните свою игру в качестве хоста, клиента или сервера
Вверху на диаграмме будут показаны входящие и исходящие сообщения
Щелкните по диаграмме, чтобы выбрать рамку
Profiler отобразит информацию обо всех сообщениях, отправленных и полученных в текущем кадре
В настоящее время в сообщениях отображаются следующие поля:
In/Out: Было ли сообщение получено (in) или отправлено (out)
Name: Краткое название сообщения, если сообщение было
[Command],[ClientRpc],[TargetRpc]или[TargetEvent], при этом будет отображено имя метода, в противном случае будет отображено имя класса message.Bytes: Размер сообщения в байтах
Count: В случае исходящих сообщений здесь будет указано, скольким клиентам было отправлено сообщение.
Total Bytes: размер сообщения, умноженный на количество клиентов, которым было отправлено сообщение (Bytes * Count)
Channel: Канал, использованный для отправки сообщения. На момент написания этой статьи мы не можем определить канал для входящих сообщений, поэтому отображается значение -1. Это будет улучшено в будущих версиях. Транспортные средства могут использовать каналы для многих целей, таких как надежные, ненадежные, зашифрованные, сжатые и т.д.
Optimizing bandwidth
На большинстве транспортных систем общая пропускная способность определяется столбцом Count. Это происходит потому, что каждое сообщение упаковано во фрейм TCP или UDP, которые имеют большие заголовки.
Если вы отправляете несколько
[Command]в одном и том же кадре рассмотрите возможность объединения их в единый[Command], если в этом есть смыслЕсли вы видите большое число Count в определенном сообщении, подумайте о добавлении NetworkProximityChecker к вашему объекту, чтобы он был виден только ближайшим игрокам, а не всему миру. Это может значительно сократить количество (и общее количество байт) в зависимости от вашей игры.
Если вы отправляете сообщение каждый отдельный кадр, подумайте о том, чтобы изменить свою логику таким образом, чтобы вы отправляли сообщения только тогда, когда что-то меняется, или используйте таймер.
Рассмотрите возможность использования функции SyncToOwner, чтобы только владелец получал сообщение при изменении личной информации, такой как инвентарь. Это может значительно сократить количество сообщений в зависимости от вашей игры.
Если у вас вызывается много
[ClientRpc]которые синхронизируют данные, рассмотрите возможность использования[SyncVar]и synclists вместо этого. Они могут уменьшить количество сообщений, потому что отправляют дельты только при их изменении, плюс они группируются вместе, так что сотни переменных могут быть синхронизированы с одним сообщением.
Last updated
