📈Performance & Tweaks
Even though LevelledMobs is written from the ground up to be performant and capable of functioning on even the lowest resource servers, some want even more. Below include some suggestions for various changes you can make to your LevelledMobs setup to squeeze every megabyte of memory and bit of processing out of the plugin.
Altering the Nametags
One of the 'most expensive' resource items would be the nametag generation and maintaining system. With previous versions of LevelledMobs we did not provide a nametag for every mob unless expressly stated; now we put one on every mob possible in an effort to spread the effects of the system to every mob.
You can utilize the Preset already located in your Rules file called nametag-disabled. This will set the nametag-visibility-method: ['DISABLED'] as well as clear the nametag field with nametag: disabled. With this set, even if a mob were affected by LevelledMobs, it's nametag would be disabled and processing for it not initialized.
The easiest mobs to apply this to would be the Passive mobs, as those include animals like schools of fish, cow/sheep/pig farms, et cetera. This alone would reduce the amount of nametags processed by probably half or more. You could also use nametag-visibility-method: ['MELEE'] to limit the processing to mobs you are explicity looking at one-at-a-time.
Adjustments in the Settings file
These settings are all located within the settings.yml file. These settings handle the flow of our resource usage while processing various aspects of the plugin.
The async-task-update-period and async-task-max-blocks-from-player settings control the master checker, updater, and validator for every mob. Anything that might have been missed, or needs to be reprocessed, et cetera is done on this timed looping mechanism. By default, it is set to run every 3 seconds for 320 blocks of distance away from every player online checking for mobs which LevelledMobs might need to reprocess. You can increase the update period, or reduce the distance from the player checked, to improve the resource usage of this process. You want to maintain an update period so that in doing the average player isn't hit with an update while they're actively handling a mob. We suggest, as a conservative value, to set it as 6 seconds and 64 blocks away from a player. This is tested to be about the lowest combined setup without obvious effects of the update being noticed.
The level-mobs-upon-spawn-max-players and update-mobs-upon-nonplayer-damage-max-players settings refer to update listener mechanisms which are constantly running listening for specified events to occur; the first being for when a mob spawns into the world and the second being when a mob receives damges from a source that wasn't a player, such as a fall or lava. The numbers specified in these settings represent how many players online it would require for this system to disable itself, as the number of players in different parts of a map would greatly increase the amount of constant checks occurring. For better resourced serves, this is not an issue. If you are running tight margins, you might disable this check entirely by setting them to 0 or by reducing the player count to a more reasonable number before it disables itself automatically. This is merely a quality of life listener, as the async task update will correct the mobs as it passes.
The setting ensure-mobs-are-levelled-on-chunk-load is a similar listener to the set above, however this is listening for when a chunk is loaded into a world. When this occurs, it quickly checks that chunk for any mobs that may or may not have been levelled. Disabling this listener would be an easy and quick way to reduce resource usage on servers with smaller viewing or world generation ranges.
The lew-cache-clear-period represents a timer which runs to empty any stale or conflicted nametag and data entries from mobs which are stored in memory for quick access by the plugin. Sometimes a loop can occur which will cause the LEW (LivingEntityWrapper) to stack with information filling memory. This is a simple cleaning mechanism to prevent this information from overflowing. A timer of 3m is the default and should be fine, though a lower number would clear the memory more frequently.
Last updated