Основано на ветке jrpm после слияния (включает функции pulsexlb и собственные оптимизации jrpm). Значения параметров по умолчанию взяты из src/table/settings/network_settings.ini, рекомендуется опираться на реальное нагрузочное тестирование.

1. Реализованные оптимизации производительности (данная версия)

Оптимизация	Коммит	Описание
Настраиваемое количество параллельных загрузок	4716b925	network.content_download_parallel (по умолч. 4, 1-8): количество одновременно загружаемых файлов, заменяет жёстко заданное 4
Несколько зеркал + файловый параллелизм	d4c45740 (F1)	network.content_mirrors через запятую, повтор при сбое зеркала, откат к старому протоколу
Совместимость сервера с несколькими версиями	cb9848b7	Сервер может одновременно принимать клиенты jrpm / оригинальный jgrpp / pulsexlb

2. Ключевые параметры производительности сервера (система jgrpp)

Настройка	По умолч.	Диапазон	Значение	Рекомендации
network.sync_freq	100	0-100	Частота синхронизации кадров (обнаружение desync). Больше = меньше трафика, меньше = раньше обнаружение рассинхронизации	Для стабильности в сети можно снизить до 20-50; при частых desync уменьшать
network.frame_freq	0	0-100	Частота отправки кадров команд. Больше = меньше трафика/CPU, но выше задержка операций	Обычно 0-3; на многолюдных серверах до 5, после нагрузочного тестирования
network.commands_per_frame	2	1-65535	Лимит команд клиента за кадр (защита от спама/злоумышленников)	При большом количестве игроков/частых операциях можно поднять до 4-8
network.commands_per_frame_server	16	1-65535	Лимит команд самого сервера за кадр	Обычно не требуется изменять
network.bytes_per_frame	8	1-65535	Средний лимит байт на кадр (формирование трафика)	При хорошем канале можно поднять до 16-32, ускоряет синхронизацию больших карт
network.bytes_per_frame_burst	256	1-65535	Лимит пиковых байт (допускает кратковременные всплески)	Поднимать вместе с предыдущим параметром, например 512
network.max_init_time	60	0-32000	Таймаут инициализации клиента (tick)	При большом количестве игроков со слабым соединением можно увеличить
network.max_join_time	500	0-32000	Таймаут подключения клиента (загрузка карты + синхронизация) (tick)	Для больших карт/медленных каналов увеличить до 1000+
network.max_download_time	1000	0-32000	Таймаут загрузки карты (tick)	Для больших карт (4096+) рекомендуется 2000+
network.max_lag_time	800	0-32000	Максимальная допустимая задержка клиента (tick)	При большом количестве игроков с высокой задержкой увеличить, но это повышает риск desync

Примечание: единица max_*_time — игровые tick (1/74 сек ≈ 13.5ms); bytes_per_frame — средние байты окна синхронизации за кадр.

3. Рекомендуемая стартовая конфигурация сервера (многопользовательская игра)

[network]
max_clients = 32            ; или по необходимости
max_companies = 15
frame_freq = 3              ; 0 = отправлять команды каждый кадр (максимальная плавность); 3 = компромисс
sync_freq = 50              ; более раннее обнаружение рассинхронизации
commands_per_frame = 8
bytes_per_frame = 16
bytes_per_frame_burst = 512
max_join_time = 1000
max_download_time = 2000
max_lag_time = 1200
content_download_parallel = 4   ; параллельность загрузки контента на стороне клиента

4. Направления будущих оптимизаций производительности (по приоритету)

1. HTTP транспортный пул потоков + Range-блочная загрузка (идея Openttd-Cluster 0007) Текущее состояние: F1 уже реализовал «файловый параллелизм» (одновременная загрузка нескольких файлов). 0007 добавляет пул потоков на HTTP-уровне + CURLOPT_RANGE для блочной загрузки, что может ускорить одиночные большие файлы (гигантские сценарии .tar.gz). Два подхода взаимодополняемы, но затрагивают одни и те же файлы, рекомендуется добавление после стабилизации F1.

2. Оптимизация отправки карты Проверить, включено ли сжатие карты по умолчанию в jrpm (zstd/lzma); для больших карт можно сравнить время разных алгоритмов сжатия.

3. Среда выполнения Rust-сервера (долгосрочная архитектурная справка) otc-engine от Openttd-Cluster (Admin/RCON, метрики Prometheus, кластерный failover, веб-панель, мост снимков) требует полной интеграции Rust-проекта через FFI, что является модернизацией уровня «сервер следующего поколения», а не слиянием на уровне патчей; jrpm пока остаётся чистым C++ единым бинарником.

4. Производительность симуляции игры

   • Для больших карт с большим количеством ТС обратить внимание на параметры economy/linkgraph (linkgraph_settings.ini);
   • Для экстремальной производительности изучить классы settings_game.economy. и параметры лимитов pathfinder (настройки pathfinding).

5. Рекомендации по проверке

• Открыть сервер openttd-jrpm -D -c server.cfg, протестировать с несколькими клиентами jrpm: время подключения, стабильность синхронизации кадров (без сообщений desync), загрузка CPU/памяти;
• Загрузка контента: установить content_download_parallel=8 и сравнить время загрузки набора NewGRF;
• Тестирование при слабом соединении: комбинация max_lag_time и sync_freq для нахождения стабильной границы.