MSPT и TPS сервера Minecraft показывают темп тиков и длительность каждого тика. Среднее значение может скрыть длинные тики, поэтому разберём, как читать тайминги Minecraft на Paper. Результат зависит от версии ядра, мира, плагинов, онлайна и метода измерения.

Чем TPS отличается от MSPT?

TPS показывает среднее число тиков в секунду, а MSPT показывает время обработки одного тика. По TPS видна устойчивая перегрузка, тогда как MSPT помогает заметить отдельные долгие тики. На оба показателя нужно смотреть с учётом окна измерения и распределения MSPT за тот же период.

Понять бюджет главного потока Minecraft

Чтобы понять, как читать тайминги Minecraft, начните с цикла сервера. При стандартном tick rate сервер должен выполнять 20 тиков в секунду, поэтому на один тик приходится 50 мс. За это время главный поток обновляет миры, сущности и блоковые сущности, выполняет запланированные задачи плагинов, обрабатывает часть сетевых пакетов и применяет изменения мира. Большая часть этой работы идёт последовательно: следующий тик не начнётся, пока не завершится текущий.

Порог 50 мс не стоит считать универсальным. Если тик закончен раньше, сервер ждёт до следующего тика. Если позже, начинает отставать и пытается наверстать время. При изменённом tick rate меняется и бюджет. Поэтому рядом с метрикой фиксируют версию ядра и целевую скорость тиков.

Серверный тик не связан напрямую с FPS клиента и ping. Низкий FPS возникает при отрисовке на компьютере игрока, а ping отражает задержку обмена по сети. Долгий тик проявляется иначе: блоки ломаются с задержкой, мобы замирают, команды и взаимодействия выполняются позже. По времени этих симптомов выбирают участок для профилирования.

Читать темп тиков с учётом сглаживания и потолка

TPS показывает средний темп за окно измерения. В выводе spark встречаются значения за несколько периодов, поэтому число нужно подписывать: «TPS за последнюю минуту», а не просто «TPS». На сервере со стандартным tick rate верхняя граница равна 20. Из-за этого ровные 20 TPS не говорят, что все тики были короткими: после одного длинного тика следующие могли завершиться быстро.

Связка 20 TPS и 50 MSPT даёт границу только для стандартного темпа. Когда средний тик стабильно занимает больше 50 мс, сервер уже не успевает поддерживать 20 TPS. Но обратный вывод другой: близкий к 20 средний TPS не исключает редкий тик на 200 или 500 мс. На длинном интервале он мало изменит среднее, хотя игрок заметит паузу.

Для устойчивой перегрузки TPS полезен: падение на минутном и пятиминутном интервале показывает, что проблема не ограничилась одним эпизодом. Для короткого лага берут временную линию MSPT и профиль того же периода. Не сравнивайте TPS из разных ядер или команд без оговорки: реализации могут использовать разные окна, округление и целевой tick rate.

Смотреть медиану и хвост времени тика

По MSPT видно распределение tick time, то есть длительности отдельных тиков. Медиана отражает обычный тик, p95 показывает границу для 95% наблюдений за выбранное окно, а максимум отмечает самый длинный эпизод. Среднее чувствительно к выбросам и не отвечает на вопрос, насколько часто они возникают. Поэтому для жалобы «раз в минуту всё зависает» важнее хвост распределения и временная линия, чем одно среднее значение.

Почему при нормальном TPS игроки всё равно видят лаги?

TPS может оставаться около целевого значения, потому что он усредняет темп за выбранное окно и имеет верхнюю границу. Игроки при этом замечают отдельные длинные тики. Похожий симптом дают паузы GC или задержки в сети. Сначала сопоставьте жалобу с MSPT, ping и профилем того же периода.

Длинный тик откладывает обработку действий всех игроков на главном потоке, поэтому дверь открывается или удар регистрируется позже. Если пики MSPT совпадают с такими паузами, дальше нужен профиль CPU. При этом старые тайминги Paper брать за основу не стоит: Paper помечает Timings устаревшими, а с 1.21 отключает их по умолчанию в пользу spark.

Снять профиль именно во время воспроизводимого лага

Диагностика лагов тика Minecraft начинается не с длинной записи «на всякий случай», а с воспроизводимого эпизода. Запишите версию Paper, Java и spark, число игроков, список миров и плагинов, view-distance и simulation-distance. Рядом опишите действие: например, перелёт в ещё не сгенерированную область, запуск фермы или массовое перемещение сущностей. Без этого профиль трудно повторить после правки.

Для общего среза можно записать 300 секунд. Если проблема состоит из редких длинных тиков, сначала включите монитор и подберите порог ниже наблюдаемого всплеска, затем запишите только тики, которые его превышают:

/spark tickmonitor --threshold-tick 80
/spark profiler start --only-ticks-over 80 --timeout 300

Порог 80 мс здесь служит примером, а не универсальным значением. Его выбирают по разрыву между длительностью обычных и проблемных тиков. После завершения второй команды spark вернёт ссылку на профиль. Перед публикацией проверьте вкладки с конфигурацией, именами миров, адресами и комментариями: ссылка публична для каждого, кто её получил.

Найти работу, которая удерживает главный поток

Профайлер spark MSPT показывает отдельно от TPS, но причину лага не называет. В viewer откройте Server thread и идите по ветке с наибольшим временем до конкретного метода, сущности или плагина. Верхние узлы вроде MinecraftServer.tickChildren() лишь объединяют работу ниже. Их доли включают дочерние вызовы, поэтому соседние уровни нельзя складывать как независимые расходы.

Публичный профиль Paper 1.21.11 от 4 августа 2026 года показывает, как читать дерево. За 30-секундное окно при одном игроке средний темп составил 0,91 TPS; медиана равнялась 1110 мс, p95 1227 мс, максимум 1282 мс. В мире было 32 695 сущностей. В ветке Server thread профилировщик отнёс 28,6 из 30 секунд к Slime.tick() и 24,9 секунды к вложенному pushEntities(). Профиль указывает не на абстрактную нехватку CPU, а на обработку столкновений огромной группы слаймов.

Вывод относится только к профилю: Paper 1.21.11, один игрок, 30 секунд, запись запущена из консоли. В другом отчёте узел с именем плагина может лишь вызывать код ядра. Гипотезу подтверждают только после спуска к дочернему узлу и проверки тем же сценарием.

Сопоставить длинные тики с событиями мира и JVM

Какой раздел таймингов обычно показывает узкое место?

1. В spark сначала откройте Server thread: именно он выполняет последовательную работу игрового тика.

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

3. Сверьте дорогой узел с временной линией и повторяемым действием. Верхний контейнер сам по себе не доказывает причину.

Снимок дерева показывает, на каких вызовах профилировщик собрал образцы CPU, но не всегда объясняет редкий всплеск. Поэтому spark profiler читают вместе с временной линией. Отметьте момент генерации чанков, autosave, массового спавна, телепортации и сборки мусора. Если тот же пик появляется после одинакового действия, гипотеза становится проверяемой.

Совпадение по времени ещё ничего не доказывает. Пауза GC может начаться рядом с сохранением мира, а рост MSPT при перелёте может идти от генерации чанков, плагина защиты территории или синхронного чтения данных. На нужном интервале раскройте дорогой путь и посмотрите, какая работа находится внизу. Невысокая общая загрузка CPU не исключает эту причину: главный поток способен упереться в одно ядро, пока остальные простаивают.

Изменить один фактор и повторить тот же сценарий

Проверка начинается с копии мира и одного изменения. Если профиль указывает на плагин из каталога plugins, временно отключите его функцию, обновите или откатите версию, не меняя одновременно дистанции и лимиты сущностей. Если дорогая ветка связана с генерацией чанков, заранее сгенерируйте тот же участок на тестовой копии. Для группы сущностей остановите источник спавна и повторите действие в той же области.

До и после правки сохраняют версию ядра, seed и состояние мира, маршрут игрока, онлайн, длительность профиля и настройки JVM. На живом сервере трудно повторить нагрузку полностью, но условия должны быть близкими, чтобы изменение не потерялось в шуме. Одного удачного прогона не хватит: повторите серию и сравните медиану, p95, максимум, TPS за одинаковое окно и симптом, который наблюдали игроки.

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

Превратить профиль в приоритет исправлений

Исправления сортируют по подтверждённому времени главного потока, а не по популярности совета. Если в viewer доминируют entities and chunks, проверяют источник массового спавна, размер активной области, генерацию мира и тяжёлые операции. Настройку выбирают по найденной ветке: снижение view-distance не исправит плагин, который синхронно обходит всех игроков каждый тик.

Если время уходит в код плагина, сначала проверяют обновление, конфигурацию и известные проблемы, затем передают разработчику ссылку на профиль и сценарий. Перенос работы в другой поток допустим только там, где API и данные поточно-безопасны; произвольная асинхронная обработка мира создаёт гонки и ошибки. Если ветка заканчивается сохранением или запросом к базе данных, уменьшают синхронную работу и проверяют задержку хранилища.

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

Рабочий цикл короткий: воспроизведите задержку, снимите профиль на том же участке, раскройте дорогую ветку и измените один фактор. Повторный замер должен улучшить не только среднее, но и хвост MSPT и симптом, который наблюдали игроки. Если симптом не изменился, гипотезу нужно пересмотреть.

Цель диагностики не удержать TPS на отметке 20, а убрать подтверждённую работу, которая растягивает тик. Для каждого вывода сохраняют версию, условия, временное окно и профиль. В таком отчёте MSPT и TPS сервера Minecraft помогают проверить причину лага и результат исправления, не ограничиваясь двумя цифрами.

Мне хотелось, чтобы всё было перед глазами: открыл одно окно — и видно, кто жив, кто нет. И чтобы если что-то падало, это было заметно даже боковым зрением.

Я посмотрел, что есть готового. Либо слишком просто — просто табличка с цифрами. Либо слишком сложно — целые системы мониторинга с серверами, базами данных и веб-мордами, которые разворачивать дольше, чем потом пользоваться.

Решил сделать сам. Идея простая: программа, которая пингует адреса и показывает результат в виде цветных карточек. Зелёная — всё хорошо. Красная — проблемы. Никаких таблиц, никаких лишних движений.

Писал с помощью нейросетки — вайбкодинг, да. Это когда ты говоришь «сделай, чтобы плитка была с зелёной точкой и крестиком», а тебе пишут код. Итеративно, шаг за шагом, с правками и переделками. Получилось, знаете, вполне рабочее приложение.

Вот что в итоге вышло:

🟢 Цветные карточки — статус видно сразу, читается за полсекунды

📊 График задержек прямо на плитке — видно динамику

⏱ Настраиваемый период статистики (10 минут, час, 6 часов, с начала запуска)

🔊 Звуковые оповещения — интернет упал, программа пикнет

📋 Шаблоны быстрого ввода — не надо вбивать 20 адресов руками

🔍 Поиск по узлам

🌙 Тёмная и светлая темы

🌐 Русский и английский интерфейс

📌 Закрепление плиток — чтобы после перезапуска всё было на месте

Программу не рекламирую, но если о ней не писать, то никто не найдет и не узнает, а так возможно будет кому-то полезна.

Программа работает на Windows, не требует установки, весит 240 КБ. Просто запускаешь и пользуешься.

Исходники открыты, если кому-то пригодится — вот ссылка:

https://github.com/AlexValyavin/PingMonitor

Также можете подписаться на мой ТГ канал, там пока ничего нет, но в процессе еще пару интересных проектов https://t.me/EngineeringHobby

Зачем нужна кассовая программа

Без нее невозможно работать с кассой. Она позволяет оформлять продажи, печатать чеки, принимать оплату и проводить возвраты, а еще связывает устройство с другим оборудованием и системой товароучета. Именно от кассовой программы во многом зависит, насколько удобно и быстро кассир сможет обслуживать покупателей.

Хорошая программа — не та, где больше функций

Логика «чем больше функций — тем лучше» не всегда работает. Гораздо важнее понять:

• Какие задачи касса должна решать сейчас?

• Каким требованиям должна соответствовать программа?

• Из чего складывается ее финальная стоимость?

• Удобно ли ее использовать на практике?

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

Шаг 1. Определите задачи, которые должна закрывать программа

Требования для небольшого магазина, кафе и сети будут отличаться.

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

Кафе или ресторану нужны совсем другие возможности. Здесь требуется работа с заказами за столиками, модификаторы блюд, технологические карты, учет ингредиентов и взаимодействие с кухней.

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

При выборе кассовой программы стоит смотреть не только на список функций, но и на то, для какого формата бизнеса она разработана. В линейке АТОЛ для малого бизнеса есть SIGMA Касса с отдельными решениями для торговли, общепита и сферы услуг. Для среднего и крупного ретейла подойдет ПО Frontol, которое позволяет автоматизировать работу сразу нескольких точек.

Шаг 2. Составьте требования к программе

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

Соответствие требованиям 54-ФЗ и наличие обновлений

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

Управление рабочим местом кассира

Кассовая программа помогает выполнять основные операции: искать товары, добавлять их в чек, принимать оплату, оформлять возвраты и печатать чеки. Еще из полезного — функции для управления доступами сотрудников: создание учетных записей кассиров, настройка прав и контроль действий разных пользователей.

Работа с маркировкой

Все больше категорий товаров переходят на обязательную маркировку, поэтому при выборе кассовой программы важно убедиться, что она поддерживает работу с системами «Честный ЗНАК» и ТС ПИоТ. Даже если сейчас в ассортименте таких позиций нет, лучше учитывать планы развития бизнеса заранее.

Поддержка ЕГАИС — если продаете алкоголь

Если такой продукции нет, переплачивать за функцию не стоит.

Базовый товарный учет

Кассовая программа позволяет хранить информацию о товарах: например, названия, цены, остатки, сроки годности.

Поддержка оборудования

Сюда входят POS-терминалы, ККТ, сканеры штрихкодов, весы, денежные ящики, банковские терминалы и принтеры этикеток. Чем больше совместимых устройств поддерживает программа, тем проще подобрать решение под конкретную торговую точку.

Интеграции с другими сервисами

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

Современные способы оплаты

Наличными, картой, через СБП или по QR. Чем меньше действий клиенту и сотруднику приходится выполнять на кассе, тем быстрее обслуживание и меньше очередей.

Гибкая настройка

Хорошо, если кассовое ПО позволяет настроить сценарии под особенности бизнеса — тогда не придется искать обходные решения.

Аналитика

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

Шаг 3. Сравните полную стоимость

Предприниматели часто смотрят на цену покупки и забывают про совокупную стоимость владения. А она складывается из нескольких частей.

Лицензия или подписка. Разберитесь, как вы платите: разово по бессрочной лицензии, ежегодно или помесячно, что входит в тариф, а что оплачивается отдельно.

Обновления. Уточните, входят ли они в стоимость. Автоматические обновления — это не только удобство, но и защита от штрафов.

Интеграции и обучение. Подключение товароучета, эквайринга, обучение кассиров — тоже деньги и время. Заложите их в бюджет сразу, чтобы внедрение не оказалось дороже, чем вы рассчитывали.

Техподдержка. Узнайте, как устроена поддержка и не оплачивается ли она отдельно.

Масштабирование. Спросите себя: что будет, когда точек станет три или пять? Программа, которая не умеет расти, вынудит вас полностью поменять оборудование и софт, а это самый дорогой сценарий.

Шаг 4. Проверьте на практике

Хорошая кассовая программа решает задачи вашего бизнеса и может развиваться вместе с ним. Но понять, насколько хорошо работает ПО, сложно без теста. Поэтому перед внедрением стоит проверить программу в работе: удобно ли кассирам выполнять ежедневные операции, насколько понятные отчеты предоставляет система, ускорилось ли обслуживание посетителей или, напротив, замедлилось. Демодоступ поможет оценить это до покупки.