Área de cliente
Optimización del servidor Minecraft
Guía completa de Spigot, Paper y Purpur (1.20-1.21)
El rendimiento de un servidor Minecraft depende de una configuración de software y hardware adecuada. Esta guía está dirigida a administradores que utilizan Spigot, Paper u otros forks similares como Purpur y Pufferfish, y cubre las versiones 1.20.x a 1.21.x. Detallaremos los ajustes esenciales de los archivos de configuración (spigot.yml, paper.yml, bukkit.yml, purpur.yml), explicaremos por qué los valores predeterminados suelen ser inadecuados y mostraremos cómo ajustes específicos mejoran el TPS, reducen la carga de la CPU y estabilizan su servidor.
Esta guía también incluye recomendaciones de plugins útiles, una comparación de las ventajas de Purpur y Pufferfish frente a Paper y Spigot, así como consejos sobre la configuración de Java (versiones, flags JVM G1GC). El contenido está organizado por secciones para una consulta rápida y eficaz.
Elegir su software de servidor
Comparación de las soluciones disponibles
| Software | Base | Ventaja principal | Recomendado para |
|---|---|---|---|
| Spigot | CraftBukkit | Compatibilidad con plugins histórica | Pequeños servidores simples |
| Paper | Spigot | Optimizaciones + opciones avanzadas | La mayoría de los servidores |
| Pufferfish | Paper | Rendimiento máximo | Servidores muy poblados |
| Purpur | Pufferfish | Personalización avanzada | Servidores que requieren opciones exóticas |
Paper en lugar de Spigot
Spigot y su predecesor CraftBukkit son la base histórica de los servidores Bukkit, pero actualmente están rezagados en términos de rendimiento en comparación con Paper. Este último es un fork de Spigot que incorpora numerosas optimizaciones y correcciones mientras mantiene una compatibilidad total con los plugins de Spigot y Bukkit. Paper también expone docenas de opciones de configuración avanzadas que permiten refinar el rendimiento sin alterar significativamente la jugabilidad.
Pufferfish para un rendimiento puro
Pufferfish es un fork de Paper que apareció en 2021, orientado completamente al rendimiento. Integra numerosos parches avanzados manteniendo la compatibilidad con la API de Paper.
Mejoras incluidas en Pufferfish:
| Funcionalidad | Descripción |
|---|---|
| Procesamiento asíncrono | Algunas entidades se procesan parcialmente en segundo plano |
| Sistema DAB | Algoritmos de IA de mobs más rápidos |
| Renderizado de mapas SIMD | Optimización a través de instrucciones vectoriales |
| Gestión de hopper | Funcionamiento más eficiente de los embudos |
| Optimización de trazado de rayos | Cálculos de líneas de visión acelerados |
| Gestión de memoria | Reducción de las pausas del recolector de basura |
| Integración Sentry.io | Reporte automático de errores del servidor |
| Profiler Flare | Análisis avanzados que incluyen el perfilado de memoria |
La mayoría de estas optimizaciones son transparentes para la jugabilidad. Aquellas que puedan tener un impacto pueden desactivarse en pufferfish.yml. Si su objetivo es soportar un gran número de jugadores con una carga alta, Pufferfish suele ser la mejor elección.
Nota : También existe Pufferfish+, una versión comercial aún más optimizada con seguimiento de entidades y pathfinding completamente asíncronos, destinada a servidores muy grandes.
Purpur para la personalización
Purpur es un fork de Paper orientado a la personalización avanzada. Técnicamente, incluye todas las optimizaciones de Pufferfish pero no agrega un rendimiento adicional propio. Sin embargo, ofrece cientos de nuevas opciones de configuración para ajustar los mecanismos de juego: posibilidad de montar ciertos mobs, calamares voladores, sueño de un solo jugador, entre otros.
Por defecto, estas características adicionales están desactivadas y el servidor se comporta como un Paper/Pufferfish estándar. Utilice Purpur solo si realmente necesita estas opciones de jugabilidad, ya que más parches pueden significar más posibles errores.
Lo que se debe evitar
| A evitar | Razón |
|---|---|
| JAR "caseros" oscuros o de pago | 99% de probabilidades de ineficacia o perjuicio |
| Servidor Vanilla puro | Diferencia de rendimiento notable con Paper |
| Permanecer en Spigot | Pierde las optimizaciones de Paper disponibles de forma gratuita |
Configuración de bukkit.yml
El archivo bukkit.yml gestiona principalmente los parámetros de spawn de entidades pasivas y hostiles. Los valores predeterminados de Bukkit/Spigot están calibrados para servidores pequeños con poca población, pero resultan excesivos para un servidor de supervivencia con muchos jugadores.
Límites de spawn (spawn-limits)
Estas cuotas definen la cantidad de mobs que pueden aparecer por jugador. Por defecto, un jugador puede tener alrededor de 70 monstruos, 10 animales y 15 criaturas acuáticas a su alrededor, lo que puede saturar rápidamente el servidor en entidades con varios jugadores conectados.
Valores recomendados :
| Categoría | Valor predeterminado | Valor recomendado |
|---|---|---|
| Monstruos | 70 | 20 a 30 |
| Animales | 10 | 5 |
| Criaturas acuáticas | 15 | 2 |
| Criaturas ambientales | 15 | 1 |
El cálculo interno multiplica estos límites por el número de jugadores conectados. Al reducir estos números, se disminuye la densidad de mobs a gestionar y se aligera la carga del servidor.
Atención : Valores demasiado bajos reducen la fauna y la dificultad del juego. Para un servidor de supervivencia "hardcore" o centrado en granjas de mobs, no los reduzca demasiado. El valor de 30 monstruos ofrece un buen equilibrio si desea mantener la acción.
Frecuencias de spawn (ticks-per)
Estos ajustes controlan la frecuencia de los intentos de spawn de nuevas entidades. Por defecto, Minecraft intenta hacer spawn de monstruos en cada tick (20 veces por segundo) y de animales cada 400 ticks (aproximadamente 20 segundos).
Valores recomendados :
| Categoría | Valor predeterminado | Valor recomendado |
|---|---|---|
| monster-spawns | 1 | 2 a 10 |
| animal-spawns | 400 | 400 |
| water-spawns | 1 | 400 |
| ambient-spawns | 1 | 400 |
Poner monster-spawns en 2 significa intentar solo una vez cada 2 ticks. La diferencia en la tasa de aparición es imperceptible para los jugadores, pero el servidor procesa la mitad de ciclos de spawn. Para las categorías acuáticas y ambientales, intervalos de 400 ticks o más son perfectamente aceptables ya que estas criaturas alcanzan rápidamente su límite de población.
Opción adicional Paper
Paper ofrece la opción per-player-mob-spawns que distribuye mejor los spawns entre los jugadores en lugar de llenar la cuota de un solo jugador antes de pasar al siguiente. Al activar esta opción, puedes permitir límites más bajos sin privar a los jugadores de encuentros: cada jugador tendrá su parte justa de mobs a su alrededor.
Configuración spigot.yml
El archivo spigot.yml contiene varios parámetros clave para controlar el alcance de actividad de las entidades y la gestión de objetos en el suelo. Los valores predeterminados buscan replicar el comportamiento en solitario, pero en multijugador pueden reducirse para ahorrar recursos.
Distancias de vista y simulación
| Parámetro | Descripción | Recomendación |
|---|---|---|
| view-distance | Distancia de renderizado de los chunks | Dejar en "default" en spigot.yml |
| simulation-distance | Distancia de actividad de las entidades | 4 chunks (server.properties o Paper) |
| view-distance (efectiva) | Chunks enviados al cliente | 7 a 10 chunks |
A partir de Minecraft 1.18+, se recomienda dejar view-distance en "default" en spigot.yml y utilizar los parámetros de distancia en server.properties o a través de Paper. El truco consiste en establecer una distancia de simulación baja (4 chunks) mientras se mantiene una distancia de vista más alta (8 a 10 chunks). De esta manera, los jugadores ven lejos pero el servidor solo calcula los alrededores cercanos.
Rango de spawn de mobs (mob-spawn-range)
Este radio en chunks determina a qué distancia del jugador pueden aparecer los mobs. Por defecto está fijado en 8 chunks (128 bloques), y puede reducirse para concentrar los spawns.
Recomendación: Ajusta este parámetro a 4 o 6 chunks si tu distancia de simulación es baja. Asegúrate de que mob-spawn-range siga siendo menor o igual que tu distancia de simulación efectiva. Al reducir este radio, incluso con límites de spawn reducidos, los jugadores sentirán que el mundo está vivo ya que los mobs aparecerán más cerca de ellos.
Rango de activación de entidades (entity-activation-range)
Este es uno de los principales impulsores de rendimiento. Define la distancia en bloques a partir de la cual las entidades dejan de estar activas (su IA está "dormida" mientras ningún jugador está cerca).
Valores recomendados:
| Categoría | Valor por defecto | Valor recomendado |
|---|---|---|
| Monstruos | 32 | 24 |
| Animales | 32 | 16 |
| Criaturas acuáticas | 32 | 8 |
| Villagers | 32 | 16 |
| Monstruos voladores (phantoms) | 32 | 48 |
| Raiders | 32 | 48 |
| Misc | 16 | 8 |
Reducir estos radios alivia la CPU ya que las entidades lejanas ya no consumen recursos. Sin embargo, valores demasiado bajos pueden romper algunos mecanismos. Por ejemplo, las granjas de hierro requieren aldeanos "activos" dentro de un cierto radio de los zombies.
Consejo: Activa también tick-inactive-villagers: false para que los aldeanos se duerman fuera del alcance del jugador. Desde la 1.14, los aldeanos tienen un gran impacto en los ticks cuando están activos en masa.
Rango de seguimiento de entidades (entity-tracking-range)
Este parámetro define a qué distancia las entidades se envían al cliente. Puede ser mayor que el rango de activación sin un costo significativo para el servidor ya que solo afecta el envío de datos a los jugadores.
Recomendación: Mantén los rangos de seguimiento un poco más altos que los rangos de activación para evitar el efecto de mobs que "aparecen" repentinamente en pantalla. Valores de 48 para la mayoría de las categorías (excepto misc a 32) son un buen compromiso.
Fusión de items y XP (merge-radius)
| Tipo | Valor por defecto | Valor recomendado |
|---|---|---|
| Items | 2.5 | 4 a 5 |
| XP | 3.0 | 6 |
Fusionar las entidades de items en el suelo reduce considerablemente la cantidad de entidades a gestionar. En lugar de 50 bolas de XP separadas, tendrás una o dos más grandes. No aumentes demasiado estos radios ya que los items podrían "teletransportarse" de un bloque a otro o atravesar paredes para juntarse.
Consejo: Paper ofrece la opción fix-items-merging-through-walls para evitar este comportamiento si amplías mucho el radio de merge.
Tiempo de vida de entidades en el suelo
| Parámetro | Valor por defecto | Valor recomendado |
|---|---|---|
| arrow-despawn-rate | 1200 ticks (1 min) | 300 ticks (15 sec) |
| item-despawn-rate | 6000 ticks (5 min) | 4000 ticks (3 min) |
Las flechas disparadas se limpiarán más rápidamente, evitando su acumulación invisible. Para los items, 3 minutos son más que suficientes para que un jugador recoja sus drops.
Nota Paper: La opción alt-item-despawn-rate permite establecer un tiempo de despawn específico para ciertos items (cobble, netherrack, gravel). Esto puede reemplazar ventajosamente un plugin de clearlag.
Otros parámetros importantes
| Parámetro | Valor recomendado | Descripción |
|---|---|---|
| nerf-spawner-mobs | true | Los mobs de spawners ya no tienen IA hasta ser tocados |
| save-user-cache-on-stop-only | true | La caché de usuarios se guarda solo al detenerse |
| max-tick-time (tile y entity) | 1000 | Desactiva casi por completo el limitador de ticks |
nerf-spawner-mobs: Si tu servidor tiene muchas granjas de spawners, esto supone un gran aumento de rendimiento. Los monstruos "nerfeados" apenas tienen costo de CPU y simplemente esperan a ser eliminados.
max-tick-time: Al establecerlo en 1000ms, desactivas el sistema de protección que puede causar comportamientos extraños (entidades o máquinas redstone que pierden ciclos). El servidor intentará siempre calcular todo como se espera, incluso si esto resulta en un TPS inferior a 20.
Configuración paper.yml
Paper y sus forks tienen configuraciones adicionales en comparación con Spigot. Estas opciones suelen ser mejoras desactivadas de forma predeterminada para mantener el comportamiento vanilla, pero una vez activadas, mejoran significativamente el rendimiento.
Optimizaciones del motor de juego
Redstone optimizada
| Opción | Valor | Descripción |
|---|---|---|
| use-faster-eigencraft-redstone | true | Activa el algoritmo EigenCraft |
| redstone-implementation | ALTERNATE_CURRENT | Alternativa según la versión |
Este nuevo motor reduce las actualizaciones redundantes de redstone y mejora significativamente el rendimiento de los circuitos complejos sin cambiar su funcionamiento observable.
Explosiones optimizadas
| Opción | Valor | Descripción |
|---|---|---|
| optimize-explosions | true | Algoritmo optimizado para TNT y creepers |
El algoritmo calcula las zonas de efecto más rápidamente con una pérdida de precisión imperceptible para los jugadores.
Anti-Xray integrado
| Opción | Valor | Descripción |
|---|---|---|
| anti-xray.enabled | true | Activa la protección |
| anti-xray.engine-mode | 2 | Modo de obfuscación recomendado |
El anti-Xray de Paper es mucho más eficiente que los plugins tradicionales. Ofusca los bloques de minerales no descubiertos reemplazando temporalmente su apariencia en los chunks enviados. Nunca uses plugins anti-Xray de terceros en Paper.
Gestión de entidades y mobs
Colisiones reducidas
| Opción | Valor por defecto | Valor recomendado |
|---|---|---|
| max-entity-collisions | 8 | 2 |
En un gran grupo de mobs, cada entidad solo se ocupará de 2 colisiones a la vez en lugar de 8, reduciendo la explosión combinatoria de cálculos.
Spawns por jugador
| Opción | Valor recomendado |
|---|---|
| per-player-mob-spawns | true |
El servidor distribuye el mobcap global equitativamente entre los jugadores, evitando que un jugador aislado acapare todos los spawns hostiles.
Optimización de los hoppers
Los embudos son conocidos por ser uno de los peores enemigos del TPS porque realizan verificaciones constantes.
| Opción | Valor | Condición |
|---|---|---|
| hopper.disable-move-event | true | Únicamente si ningún plugin escucha InventoryMoveItemEvent |
| hopper-transfer (spigot.yml) | 8 | Valor por defecto aceptable |
| hopper-check (spigot.yml) | 8 | En lugar de 1 por defecto |
| hopper.ignore-occluding-blocks | true | Desactiva un comportamiento vanilla poco utilizado |
Al desactivar disable-move-event, evitas que el servidor genere un evento en cada movimiento de ítem en un hopper. Esto supone una mejora masiva de rendimiento en servidores llenos de circuitos de clasificación.
Atención : Si usas plugins de protección de cofres o de registro de ítems movidos, no desactives esta opción.
Optimizaciones de aldeanos
| Opción | Valor | Descripción |
|---|---|---|
| tick-inactive-villagers | false | Los aldeanos se duermen fuera del alcance del jugador |
| villager.lobotomize (Purpur) | true | Elimina la IA de los aldeanos demasiado lejos de su objetivo |
| villager.search-radius.* (Purpur) | 16 | Reduce los radios de búsqueda de cama/trabajo |
Opciones diversas de Purpur
| Opción | Valor | Descripción |
|---|---|---|
| zombie.aggressive-towards-villager-when-lagging | false | Los zombies dejan de perseguir a los aldeanos en caso de lag |
| entities-can-use-portals | false | Impide que las entidades atraviesen portales |
| use-alternate-keepalive | true | Evita desconexiones de jugadores lentos |
Carga de chunks y mundo
Protección contra chunks no cargados
| Opción | Valor recomendado |
|---|---|
| prevent-moving-into-unloaded-chunks | true |
Esta opción evita que un jugador demasiado rápido (por ejemplo, con elytra) entre en un chunk aún no generado, lo que provocaría una carga síncrona muy costosa que podría congelar el servidor.
Retraso de descarga de chunks
| Opción | Valor recomendado |
|---|---|
| delay-chunk-unloads-by | 10s |
Si un jugador va y viene rápidamente, el servidor no cargará/descargará constantemente los mismos chunks. Esto evita operaciones de E/S y CPU repetitivas.
Mapas del tesoro
| Opción | Valor | Descripción |
|---|---|---|
| treasure-maps.enabled | false | Desactiva completamente los mapas del tesoro |
| treasure-maps.find-already-discovered | true | Los mapas apuntan a estructuras ya descubiertas |
Los mapas del tesoro pueden causar picos de lag enormes si buscan estructuras muy lejanas. Si decides conservarlos, asegúrate de tener un worldborder y preferiblemente haber pregenerado el interior.
Pregeneración del mundo
Desde las versiones 1.18+, Mojang ha optimizado la generación de terreno y la carga asíncrona. La pregeneración ya no es indispensable excepto en CPUs muy lentas. Sin embargo, para el lanzamiento de un servidor, puedes usar un plugin como Chunky para pregenerar el interior de tu worldborder.
Consejo : Coloca un worldborder en cada uno de tus mundos (Mundo, Nether, End) para evitar que los jugadores se alejen infinitamente generando terreno innecesariamente. La border del Nether debe ser 8 veces más pequeña proporcionalmente.
Plugins de rendimiento recomendados
Tabla resumen
| Plugin | Función | Indispensable |
|---|---|---|
| Spark | Profiler CPU y memoria | ✅ Sí |
| Timings (integrado) | Informe de tareas pesadas | ✅ Sí |
| FarmLimiter/FarmControl | Limita los agrupamientos de entidades | Según necesidad |
| Chunky | Generación previa de mundo | Según sea necesario |
| VillagerOptimizer | Reduce la frecuencia de las tareas de los aldeanos | Según sea necesario |
| ClearLag | Limpieza periódica de entidades | ⚠️ Parche |
Spark
Esencial para perfilar su servidor. Spark permite grabar perfiles de rendimiento de CPU y memoria en tiempo real.
Comandos útiles:
| Comando | Función |
|---|---|
/spark profiler | Inicia la grabación |
/spark profiler --stop | Detiene y genera el informe |
/spark tps | Muestra el TPS actual |
/spark health | Estado de salud del servidor |
/spark gc | Información sobre el recolector de basura |
/spark profiler --memory | Rastrea las fugas de memoria |
Es la herramienta perfecta para identificar la causa de sus lag spikes: descubrir que un cierto tipo de mob o una función de un plugin está acaparando el 40% del tiempo de tick.
Timings (integrado en Paper/Spigot)
El comando /timings report genera un informe de las tareas más pesadas desde el último reinicio. Paper mejora significativamente esta herramienta en comparación con Spigot, proporcionando gráficos de carga y detalles de los eventos más costosos.
FarmLimiter / FarmControl
Este tipo de plugin monitorea y limita el tamaño de los grupos de entidades en granjas AFK. Un problema común: los jugadores crean enormes granjas de mobs o 500 vacas en un espacio pequeño.
Funcionamiento: Más allá de un umbral (por ejemplo, 30 mobs del mismo tipo en un radio dado), se bloquean los nuevos spawns o se eliminan gradualmente los mobs excedentes.
ClearLag
Plugin conocido que limpia periódicamente las entidades en el suelo y los mobs excedentes.
Opinión: ClearLag puede resolver puntualmente una sobrecarga, pero es más un parche que una solución a largo plazo. Configurar adecuadamente los despawn y merges de items a menudo hace que ClearLag sea innecesario. Además, ClearLag en sí mismo consume recursos al escanear regularmente todas las entidades.
Chunky
Plugin de generación previa de mundo simple y eficaz. Usted define un radio o bordes y llena gradualmente todos los chunks. Funciona de forma asíncrona para no colapsar su servidor durante la operación.
VillagerOptimizer
Si sus aldeanos siguen siendo un problema a pesar de los ajustes, este plugin reduce la frecuencia de sus tareas costosas (búsqueda de cama, pathfinding). Es similar a los ajustes de Purpur pero utilizable en Spigot/Paper.
Lo que se debe evitar
| A evitar | Razón |
|---|---|
| Plugins "milagrosos" que prometen multithreading | 99% ineficaces o peligrosos |
Comando /reload en producción | Provoca fugas de memoria y caídas |
| Cargar/descargar plugins en caliente | Incoherencias e inestabilidad |
Siempre es preferible reiniciar limpiamente el servidor después de agregar o quitar plugins.
Configuración Java y JVM
Optimizar Minecraft no se limita a las configuraciones del juego: el entorno de ejecución Java y los recursos asignados también son importantes.
Versión de Java requerida
| Versión de Minecraft | Versión mínima de Java |
|---|---|
| 1.17 y anteriores | Java 8 o 11 |
| 1.18 a 1.20.4 | Java 17 |
| 1.20.5 y superiores | Java 21 |
Evite Java 8 o 11 en servidores modernos. Las mejoras en el lenguaje y el recolector de basura en Java 17/21 aportan ganancias de rendimiento y estabilidad significativas.
Configuración del Recolector de Basura
El servidor de Minecraft utiliza intensivamente la memoria, generando muchos objetos temporales. Una mala configuración del GC puede causar pausas de varios cientos de milisegundos.
Principios recomendados:
| Principio | Recomendación |
|---|---|
| RAM suficiente | 8 GB para un servidor clásico de 50 jugadores |
| Xms = Xmx | Definir el mismo valor para heap min y max |
| Recolector de Basura | G1GC (por defecto en Java 17+) |
| Generador de flags | Usar flags.sh para obtener las flags óptimas |
Ejemplo de línea de comando:
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -jar server.jar nogui
Consejo: Utilice el generador de flags en flags.sh que proporciona automáticamente la línea de comando adecuada según su versión de Java y la RAM a asignar.
Monitoreo del GC
El comando /spark gc o algunos timings pueden indicarle el porcentaje de tiempo dedicado al GC. Idealmente, esto debe mantenerse bajo (inferior al 5%). Si observa pausas frecuentes, aumente la RAM o diagnostique posibles fugas de memoria.
Alternativas de JVM
| JVM | Recomendación |
|---|---|
| OpenJ9 | ⚠️ No soportada oficialmente |
| GraalVM | ⚠️ No soportada oficialmente |
| HotSpot (estándar) | ✅ Recomendada |
Aunque existen alternativas de JVM, Paper y Spigot no las admiten oficialmente y pueden causar problemas impredecibles.
Consejos del sistema
| Componente | Recomendación |
|---|---|
| CPU | Privilegiar la frecuencia sobre el número de núcleos |
| Almacenamiento | SSD/NVMe para el mundo |
| network-compression-threshold | 256 (por defecto) o 512 para servidores con 100+ jugadores |
Minecraft es principalmente monohilo. Por lo tanto, la frecuencia y el IPC del procesador son más importantes que el número de núcleos.
Conclusión y recomendaciones
Al seguir las recomendaciones de esta guía, obtendrá un servidor considerablemente más estable y eficiente, capaz de mantener 20 TPS en situaciones donde la configuración predeterminada habría fallado.
Resumen de los puntos clave
| Área | Acción prioritaria |
|---|---|
| Software del servidor | Cambiar a Paper o un fork optimizado |
| Distancias | Reducir simulation-distance y activation ranges |
| Spawns | Disminuir los límites y aumentar los intervalos |
| Entidades | Activar nerf-spawner-mobs y tick-inactive-villagers: false |
| Redstone | Activar el algoritmo alternativo de Paper |
| Hoppers | Aumentar hopper-check y desactivar move-event si es posible |
| Monitoreo | Usar Spark regularmente |
Prácticas recomendadas continuas
Vigile constantemente: Utilice Spark para identificar las fuentes de retraso. La optimización es un proceso continuo ya que cada nueva granja o complemento agregado puede introducir un punto débil.
Establezca límites: No permita que los jugadores hagan lo que quieran en detrimento del servidor. Anuncie claramente sus reglas de entidades y utilice herramientas para hacer que se cumplan automáticamente.
Acepte compromisos: Un servidor 100% vanilla en términos de comportamiento y 100% fluido no existe para una carga alta. ¿Es mejor tener aldeanos un poco menos "inteligentes" o un spawn de 200 aldeanos que paraliza todo? La respuesta es rápida.
Actualice de manera inteligente: Mantenga actualizados sus software (Paper, Purpur) ya que a menudo incorporan nuevas optimizaciones. Lea los registros de cambios y manténgase informado sobre evoluciones como Folia, el futuro servidor multi-threaded de Paper.
Cada servidor es único. Esta guía le proporciona una base sólida para refinar: pruebe gradualmente los cambios (idealmente uno por uno), mida el impacto a través de Spark o timings, y ajuste según sus observaciones.
Para probar estas optimizaciones en una infraestructura de alto rendimiento, ¡descubra nuestras ofertas de servidores Minecraft gratuitos y experimente la diferencia en condiciones reales!