Entender y optimizar el TPS de un servidor Minecraft
Por Benjamin D. · PDG
· Lectura 7 min
Índice
El TPS servidor Minecraft indica cuántos ticks por segundo procesa el mundo, y el objetivo es siempre 20: por debajo de ese número el juego empieza a ir a cámara lenta, los cofres tardan en abrir y las granjas de redstone dejan de funcionar como deberían. Recuperar los 20 ticks pasa por saber qué está consumiendo la CPU y corregirlo con ajustes concretos.
TPS servidor Minecraft: qué mide y por qué marca la fluidez
El TPS (ticks per second) es la unidad con la que Minecraft procesa cada acción del mundo: movimiento de entidades, crecimiento de cultivos, circuitos de redstone, físicas de bloques. Cada tick dura en teoría 50 milisegundos, lo que da 20 ticks por segundo cuando todo va bien.
Cuando el servidor tarda más de 50 ms en procesar un tick, el motor lo compensa saltándose trabajo o alargando el ciclo, y el TPS cae. El jugador lo nota como saltos en el movimiento, mobs que se congelan un instante o comandos que tardan en ejecutarse.
| TPS observado | Sensación en juego |
|---|---|
| 20 | Fluido, sin retardo perceptible |
| 15 a 19 | Micro tirones, redstone algo lenta |
| 10 a 14 | Mobs erráticos, hornos y cultivos ralentizados |
| Menos de 10 | Servidor prácticamente congelado |
Cuando el problema viene del hardware más que de la configuración, la base cuenta tanto como los ajustes: un hosting Minecraft con CPU dedicada y NVMe reduce la latencia de disco y deja más margen de ticks antes de saturarse.
Qué hace caer los ticks: chunks, entidades, redstone y mobs
La mayoría de caídas de rendimiento no vienen de un solo problema, sino de la suma de varios elementos que compiten por el mismo hilo principal del servidor. Identificar cuál pesa más es el primer paso antes de tocar cualquier archivo de configuración.
Chunks cargados y distancia de vista
Cada chunk cargado obliga al servidor a simular bloques, entidades y luz dentro de esa zona. Un view-distance alto en un mapa grande con muchos jugadores dispersos multiplica el trabajo por tick, incluso sin nada especial ocurriendo dentro de esos chunks.
Entidades y redstone
Los ítems tirados en el suelo, los animales sin límite y los circuitos de redstone que se disparan sin parar generan cálculos constantes. Una granja automática mal diseñada, con hoppers moviendo ítems cada tick, puede consumir tanto como decenas de jugadores activos.
Mobs y spawn descontrolado
El spawneo natural de mobs sin control, sumado a mazmorras o granjas de experiencia muy productivas, acumula entidades vivas que el servidor debe procesar en cada ciclo. Sin límites de spawn ajustados, la cifra de mobs crece hasta convertirse en el principal cuello de botella.
Cómo medir el TPS con comandos y plugins de diagnóstico
Antes de cambiar nada hay que confirmar qué está pasando realmente. Adivinar la causa sin datos suele llevar a tocar parámetros que no afectan al problema real.
Comando /tps y /forge tps
En servidores basados en Paper o Spigot, el comando de consola muestra el TPS medio de los últimos 1, 5 y 15 minutos:
/tps
TPS from last 1m, 5m, 15m: 19.8, 19.5, 18.9En instalaciones Forge, el equivalente es /forge tps, que además desglosa el tiempo por dimensión, útil para saber si el problema está en el Nether, el End o el mundo principal.
Plugins Spark y Timings
El plugin Spark genera un perfil detallado de qué plugins, entidades o bloques consumen más tiempo por tick, con un enlace web donde se visualiza el desglose completo. Se instala como cualquier plugin, colocándolo en la carpeta plugins del servidor.
/spark profiler start
/spark profiler stopEl sistema Timings, integrado en Paper, ofrece un informe similar centrado en el rendimiento de cada plugin cargado. Ambas herramientas se consultan desde la consola del panel sin necesidad de acceso directo a la máquina.
Ajustes de configuración para recuperar los 20 ticks
Una vez identificado el origen de la caída, los ajustes se aplican en archivos concretos. La mayoría de servidores modernos basados en Paper permiten afinar este comportamiento sin tocar el código del juego.
server.properties y paper-world-defaults.yml
Reducir la distancia de vista y de simulación baja de forma directa la carga por tick, sobre todo en mapas grandes:
view-distance=8
simulation-distance=6
max-tick-time=60000En paper-world-defaults.yml se pueden ajustar los rangos de activación de entidades, para que los mobs lejos de un jugador dejen de procesarse a plena velocidad:
entity-activation-range:
animals: 16
monsters: 24
raiders: 48
misc: 8Límites de mobs y entidades
Bajar los límites de spawn en spigot.yml evita que el número de mobs crezca sin control:
spawn-limits:
monsters: 50
animals: 10
water-animals: 5
ambient: 5Estos valores se ajustan según el tipo de servidor: una comunidad de supervivencia pura tolera límites más bajos que un mapa pensado para granjas de mobs.
Redstone y hoppers
El parámetro hopper-transfer controla cada cuántos ticks se mueve un ítem entre hoppers; subirlo de 8 a 20 alivia mucho la carga sin que el jugador note diferencia real en la velocidad de las granjas automáticas. Es uno de los cambios con mejor relación entre ganancia de TPS y pérdida de comodidad.
Mantenimiento para que el TPS se mantenga estable
Recuperar 20 ticks una vez no sirve de mucho si el servidor vuelve a degradarse en unas semanas. El mantenimiento regular evita que los mismos problemas reaparezcan.
- Reiniciar el servidor con un horario fijo limpia entidades acumuladas y libera memoria fragmentada.
- Actualizar Paper o Forge a builds recientes suele incluir mejoras de rendimiento sin cambiar la jugabilidad.
- Revisar periódicamente el listado de plugins activos y desactivar los que no se usan reduce el trabajo por tick.
- Programar copias de seguridad automáticas fuera de las horas de mayor actividad evita picos de disco que se suman a la carga.
Para comunidades con varios mundos o modpacks pesados, vale la pena revisar también la Todos nuestros servidores de juegos disponibles y comparar cómo se gestionan los recursos entre distintos títulos, ya que las mismas técnicas de perfilado aplican en buena medida a otros juegos con simulación intensiva.
Si el proyecto crece hasta necesitar aislar servicios adicionales, como un bot de moderación o un panel externo, conviene revisar el Alojamiento de bots de Discord como recurso complementario sin sobrecargar el mismo proceso del juego.
Conclusión
Si el TPS cae, empieza siempre por medir con Spark antes de tocar configuración a ciegas. En la mayoría de casos el culpable es un grupo reducido de plugins, hoppers o granjas de mobs, no el hardware en sí. Ajusta primero eso, y solo después revisa distancia de vista y límites de spawn.
FAQ
¿Por qué el TPS baja solo cuando hay muchos jugadores conectados a la vez?
Cada jugador conectado obliga al servidor a cargar los chunks a su alrededor, sincronizar su inventario y procesar sus interacciones en cada tick. Si varios jugadores están dispersos por el mapa en lugar de agrupados, el número total de chunks activos crece mucho más rápido que el número de jugadores, lo que explica caídas de rendimiento desproporcionadas respecto a la cantidad de gente conectada.
¿El TPS bajo afecta a la velocidad de crecimiento de cultivos y hornos?
Sí, porque el crecimiento de cultivos, la cocción en hornos y el progreso de las pociones dependen directamente de ticks aleatorios y de ticks de bloque que se calculan al mismo ritmo que el resto del mundo. Con un TPS por debajo de 20, estos procesos se ralentizan de forma proporcional, aunque el jugador no siempre lo relacione de inmediato con el rendimiento general.
¿Cuál es la diferencia entre TPS y MSPT?
El TPS es una media que resume cuántos ticks se completan por segundo, mientras que el MSPT (milisegundos por tick) mide el tiempo real que tarda cada tick individual en procesarse. Un servidor puede mostrar 20 TPS de media y aun así tener picos puntuales de MSPT alto, por eso revisar ambos valores juntos da una imagen mucho más precisa del rendimiento real.
