Требования к оборудованию и сети для серверов на Source Engine

Source engine — это 3D игровой движок, разработанный компанией Valve. Source engine хорошо известен своими достижениями в области физики, ИИ и графики, которые сделали игры реалистичными для своего времени, при этом оставаясь масштабируемым на старом, менее мощном оборудовании. Серверы Source engine — это игровые сервисы, размещённые в сети, которые позволяют игрокам подключаться и играть вместе в мире сервера. Серверы на Source engine можно настраивать с помощью модов, что даёт уникальный и часто увлекательный игровой опыт для всех подключённых к серверу игроков.

Игры, работающие на Source engine, включают Team Fortress 2, Counter-Strike: Source, Garry's Mod и многие другие!

Часто задаваемый вопрос — какие требования к оборудованию и сети нужны для запуска сервера на Source engine, а также как это сравнивается с серверами в других играх, таких как Minecraft и Rust. Ответ на этот вопрос — это действительно зависит от обстоятельств.

Хотя серверы на Source engine значительно легче по использованию оперативной памяти по сравнению с другими играми, такими как Minecraft и Rust, они в основном однопоточные. Это значит, что процессор с малым количеством ядер, но высокой однопоточной производительностью будет работать лучше, чем процессор с большим количеством ядер, но низкой однопоточной производительностью, для серверов на Source engine. Это особенно верно, если вы планируете хостить интенсивный игровой режим или хотите, чтобы к серверу одновременно подключалось много игроков.

С учётом этого, вот список дополнительных факторов, которые стоит учитывать при выборе требований к оборудованию и сети.

• Пиковое количество игроков, которые будут одновременно подключены и играть на сервере.
• Игровой режим, количество модов и типы карт, которые запускает сервер.
• Тикрейт сервера.
• Значения ConVar сервера, связанные с производительностью.

Если вы хотите добиться абсолютно лучшей производительности и у вас есть на это средства, я лично рекомендую искать сервер с процессором из списка, например, самых высоко оцененных бенчмарков CPU по однопоточной производительности от Passmark.

Одновременные игроки

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

Хотя нет общего правила или ориентира относительно однопоточной скорости и количества игроков, поскольку существует много других переменных, если вы планируете иметь много игроков, одновременно подключённых к серверу, вам стоит постараться приобрести более современный CPU с более высокой однопоточной производительностью.

Игровой режим, количество модов и типы карт

Это очень важные факторы, которые следует учитывать при определении требований к серверу. Например, сервер, запускающий игровой режим, такой как Deathmatch в Counter-Strike: Source, где игроки постоянно стреляют друг в друга, возрождаются и бегают по карте, скорее всего, будет потреблять больше ресурсов, чем сервер, запускающий режим, в котором после смерти игроки не возрождаются до следующего раунда.

С учётом этого, карты с тесными помещениями или карты, использующие много физических пропов, скорее всего, будут потреблять больше мощности CPU, чем большая и более открытая карта.

Тикрейт сервера

Тикрейт — это то, как часто сервер симулирует игру. По умолчанию тикрейт сервера установлен на 66.66... (каждые 15мс). Это значение можно изменить с помощью аргумента командной строки -tickrate в команде запуска сервера, если игра или мод позволяют администраторам сервера изменять его.

Чем выше тикрейт сервера, тем больше требуется мощности CPU и пропускной способности сети. Это также приводит к тому, что сервер отправляет и получает больше обновлений клиентам, что улучшает задержку клиента, регистрацию попаданий и многое другое!

В Garry's Mod существует множество серверов, вмещающих до 128 одновременно подключённых игроков. Они способны на это благодаря запуску низкого значения тикрейта, например 33 или 22, что в большинстве случаев (в зависимости от сервера, конечно) достаточно низко, чтобы CPU справлялся с общей нагрузкой сервера.

Значения ConVar, связанные с производительностью сервера

Существует несколько ConVar, связанных с производительностью сервера, которые можно изменить на сервере и которые влияют на то, сколько CPU и пропускной способности потребляет ваш сервер. При этом эти настройки могут влиять на задержку клиента, количество потерянных пакетов, choke и многое другое.

Вот список некоторых ConVar, связанных с производительностью, которые я считаю наиболее полезными.

• sv_maxrate - Максимально допустимая скорость передачи данных клиента (как входящая, так и исходящая) в секунду на сервере в «байтах». Установка значения 0 означает неограниченно и рекомендуется, если у вас достаточно сетевых и аппаратных ресурсов.
• sv_minrate - Минимально допустимая скорость передачи данных клиента (как входящая, так и исходящая) в секунду на сервере в «байтах».
• sv_maxupdaterate - Максимальное количество пакетов обновления в секунду, которые сервер может отправить клиенту. Обычно равно значению тикрейта вашего сервера. Однако в некоторых случаях его можно снизить, чтобы уменьшить нагрузку на CPU или снизить потребление трафика.
• sv_minupdaterate - Минимальное количество пакетов обновления в секунду, которые сервер может отправить клиенту. Обычно находится в диапазоне от 0 до половины значения тикрейта вашего сервера (например, 33).
• sv_maxcmdrate - Максимальное количество пакетов команд в секунду, которые сервер может отправить клиенту. Обычно равно значению тикрейта вашего сервера. Однако в некоторых случаях его можно снизить, чтобы уменьшить нагрузку на CPU или снизить потребление трафика.
• sv_mincmdrate - Минимальное количество пакетов команд в секунду, которые сервер может отправить клиенту. Обычно находится в диапазоне от 0 до половины значения тикрейта вашего сервера (например, 33).
• net_splitpacket_maxrate - Максимальное количество байт в секунду, которые сервер может отправить в виде разделённых (split) пакетов клиенту. Установка более высокого значения, например 128000, может помочь в ситуациях, когда возникает «choke» при одновременной передаче большого объёма сетевых данных.
• net_maxcleartime - Максимальное время в секундах, которое сервер потратит на обработку и отправку сетевых данных за один тик. Установка низкого значения, например 0.001, может снизить choke в определённых ситуациях, но потребует больше вычислительной мощности CPU.
• sv_parallel_sendsnapshot - При значении 1 позволяет серверу использовать отдельный поток для подготовки снимков состояния игры (game state snapshots) для каждого клиента. Это может значительно улучшить производительность сервера в условиях большого количества игроков.

Я рекомендую почитать про Source Multiplayer Networking, чтобы лучше понять, на какие значения стоит устанавливать эти параметры. Также я нашёл эту тему от NFOservers.com чрезвычайно информативной и полезной!

Если вы используете провайдера выделенного хостинга (dedicated hosting), скорее всего у вас будет достаточно сетевой пропускной способности, чтобы установить эти значения ConVar на высокие/неограниченные. В этом случае следующие значения должны подойти в большинстве случаев.

sv_maxrate 0
sv_minrate 75000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_maxcmdrate 66
sv_mincmdrate 20
net_splitpacket_maxrate 128000
net_maxcleartime 0.001
sv_parallel_sendsnapshot 1

Если вы всё ещё не уверены, какие значения следует установить для этих связанных с производительностью ConVar, я рекомендую использовать такой инструмент, как этот, для расчёта значений. Также рекомендуется провести тест скорости сети с помощью таких инструментов, как SpeedTest.net или CloudFlare, чтобы узнать скорость загрузки и выгрузки вашего сервера. Эти показатели сети играют большую роль в том, сколько игроков может одновременно находиться на сервере, прежде чем возникнут проблемы с сетью, такие как потеря пакетов и т.д. (особенно ваша скорость отдачи (upload), так как она показывает объём пропускной способности, который вы можете отправлять всем игрокам одновременно через Интернет).

Мониторинг производительности сервера

Лучший встроенный инструмент для мониторинга производительности сервера в играх на Source engine - это встроенный Net Graph. Вы можете отобразить net graph, изменив значение net_graph в консоли разработчика с 0 на 4.

Этот инструмент отображает объём трафика, который вы отправляете и получаете от сервера, к которому подключены, FPS сервера, количество обновлений, отправляемых и получаемых вами и сервером, и многое другое!

Более подробное объяснение Net Graph можно найти здесь.

Вот некоторая информация с ранее упомянутой страницы Wiki:

Область 1

Эта область является легендой для цветов, используемых в разделе полезной нагрузки (payload) графика. Если часть полезной нагрузки поступает, но не подходит ни под одну из предопределённых категорий, она отображается в прозрачной зоне между последним цветом и маленькой белой точкой, обозначающей полный размер пакета (см. индикатор a на изображении)

Область 2

Для пакетов больше 300 байт, находящихся в 95-м процентиле, размер пакета отображается текстом в верхней части области полезной нагрузки (см. маркер 2). Обратите внимание, что технология Orange Box использует сжатие пакетов, но размеры, отображаемые в полезной нагрузке net_graph, основаны на размере распакованной (decompressed) полезной нагрузки.

Область 3

Количество кадров в секунду локального подключения и время отклика (ping) до сервера показаны в области 3.

Область 4

Эта область показывает текущее использование пропускной способности. in/out показывают размер в байтах последнего входящего и исходящего пакета. k/s показывает количество килобайт в секунду (скользящее среднее), недавно замеченное в каждом направлении.

Область 5

Эта область показывает производительность сервера, к которому подключён клиент. Метка sv показывает FPS сервера на момент последнего сетевого обновления, доставленного клиенту. var показывает стандартное отклонение времени кадра сервера (frametime) (где server fps = 1.0 / frametime) за последние 50 кадров, зафиксированных сервером. Если частота кадров сервера ниже 20 fps, эта линия будет отображаться жёлтым цветом. Если частота кадров сервера ниже 10 fps, эта линия будет отображаться красным цветом.

Область 6

Индикатор lerp показывает количество миллисекунд интерполяции, используемой клиентом. Некоторые заметки о значении lerp приведены ниже.

Area 7

Эта область показывает текущую настройку cl_updaterate пользователя, реальное количество обновлений в секунду, фактически полученных от сервера, реальное количество пакетов в секунду, отправленных на сервер, и настройку cl_cmdrate пользователя (которая означает желаемое количество пакетов в секунду для отправки на сервер).

Area 8

Когда net_graphshowlatency равен 1, эта область показывает историческое представление задержки соединения. Высота (обозначена маркером d) соответствует времени net_graphmsecs (на самом деле сверху есть небольшой запас после net_graphmsecs, чтобы вместились текстовые поля). Красные вертикальные линии указывают на потерянные пакеты от сервера к клиенту. Если на графике отображается жёлтый маркер (как в позиции c), это означает, что серверу пришлось придержать один или несколько пакетов перед отправкой обновления клиенту.

Area 9

Когда net_graphshowinterp равен 1, эта область показывает для каждого кадра клиента, сколько интерполяции потребовалось. Если между пакетами возникает большой разрыв (потеря пакетов, слишком низкий FPS сервера и т.д.), клиенту не будет хватать данных для интерполяции, и он начнёт экстраполировать. Экстраполяция отображается оранжевыми столбиками, поднимающимися над белой линией (пример серии экстраполяции виден чуть левее маркера 9). Кроме того, самый нижний пиксель показывает, был ли отправлен пакет CUserCmd (usercmd) на этом кадре рендеринга, или он был задержан клиентом и агрегирован из-за настройки cl_cmdrate пользователя.

Выделенный хостинг VS LAN-сервер

Хотя вы можете разместить публичный сервер на своей домашней сети (LAN), это не рекомендуется. Вместо этого стоит приобрести сервер у провайдера выделенного хостинга.

Хотя абонентская плата, часто сопутствующая выделенному хостингу, зачастую считается серьёзным минусом, вот причины использовать выделенный хостинг:

• Лучшая защита от (D)DoS-атак благодаря более высокой пропускной способности сети и системам защиты, специально созданным для отражения атак.
• Лучшая маршрутизация клиентов и меньшая задержка.
• Более стабильная работа (например, при отключении электричества дома сервер не окажется недоступен).

Кроме того, вот несколько причин не размещать сервер дома.

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

См. также

• NFOservers - Руководство по устранению задержек в играх Valve
• Valve - Source Multiplayer Networking
• Source Dedicated Server Rate Calculator 2015
• Valve - TF2 Net Graph

https://moddingcommunity.com/blog/how-to-download-run-steamcmd/

Заключение

На этом данное руководство/база знаний завершается. Теперь у вас должно быть более чёткое понимание того, какое оборудование и сеть требуются для запуска сервера на движке Source.

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

Присоединяйтесь к нашему Discord-серверу!