Lag

First of all AsyncWorldEdit does not re-implement WorldEdit it uses only WorldEdit API and WorldEdit classes. There fore it was impossible (at the moment) to make all the WorldEdit operations lag safe. In addition the amount of available time caused that not all WorldEdit operations got asynced.

== Whats not asynced? ==

• Chunk regen - uses native bukkit API, cant hook into this,
• Copy operation - no way to hook in to this atm,
• All the clipboard manipulation functions (rotate, flip, etc.) - moved to planed features
• Loading saving schematics (pasting is async!) - moved to planed features

== Server side lag == Your server might lag (when using AWE) mainly because of:

To high //blocks// (or //blocks-vip//) value

To low //interval// value

Connection to slow

Not enough RAM

To slow CPU (Physics freeze)

Block loggers

Block access controllers

=== To high //blocks// (or //blocks-vip//) value === Each time AWE performs an block placing operation it places a certain amount of blocks (//blocks// + //blocks-vip//). If this value is to large the server spends to much time at placing blocks (sending to clients, saving to disks etc.). To eliminate lag caused by to many blocks changed in a package you should lower the //blocks// and //blocks-vip// values.

For a low end server you should not go over the 1000 to 2000 for each value (2000 to 4000 in total). For a high end server you could go up to 50000 in total.

=== To low //interval// value === Even if you have a low number of block being processed in each AWE package it still might cause your server to lag. Sometimes its best to leave the //blocks// and //blocks-vip/ values on a higher value and increase the //interval// value. This value is used to determine how often AWE places blocks on the map. If your server lags because of the map changing to often you should increase the //interval// value.

For a low end server an optimal value is larger then 30 (placing blocks each 1.5s).

=== Connection to slow === Each time a chunk changes the server needs to send it to all the players. If you do large world edits that affect multiple chunks you could max out your Internet connection. To fix this issue you could increase the //interval// value. You also could lower the number of blocks changed each interval (//blocks// or //blocks-vip//).

=== Not enough RAM === If your server (the physical machine) is running low on RAM the server might and probably will lag when doing large WorldEdits! In general this is caused because when the RAM on the physical machine starts to run out the OS starts using the swap space on your hard drive. This allows it to allocate more RAM then the physical machine actually has but increases the time it takes to read/write the memory.

You could also run out of server allocated memory this almost always ends with a crash :)

There are few thing you can do:

Get more RAM!

Remove plugins from your server

Lower the number of allowed players

Lower the //queue-limit-hard//, //queue-limit-soft// and //queue-max-size// in AWE config

Disable physics freeze

=== Physics freeze === Physics freeze is an feature that allows you to make your WorldEdit operations more clean. It is mostly useful when editing falling blocks (sand, gravel) or liquids (lava, water). Physics freeze stops the blocks physics until all adjacent blocks are placed. This feature requires additional amounts of memory and cpu power. If your server is lagging because of low memory or high cpu usage and you don't mind making a mess when editing liquids you should disable this (//physicsFreez// in config). Although this feature is not mandatory I recommend that you don't disable it. If the cause of lag is low memory you should consider lowering the //queue-limit-hard//, //queue-limit-soft// and //queue-max-size//. Or simply try to get more free memory on the server.

=== Block loggers === The block logging is handled through my other plugin http://dev.bukkit.org/bukkit-plugins/blockshub/. Through it all block place events are forwarded to block logger plugins. All block logger plugins need to store the block place/destroy data on the disk and this can take time. If you are making large edits and you have set a high //blocks// value and low //interval// value the block logger plugin might receive large amounts of data thet it needs to store. When enabling block logging you can check who placed a block using WorldEdit but at a price of increasing the time it takes to place a single block. This is not an issue when you edit small amount's of blocks but can increase significantly the time it takes AWE to place the blocks package.

If you are lagging because of the block logger feature you might consider disabling it if you don't need to know who did a WorldEdit operation (WorldEdit available only for staff, players can use WorldEdit only on there plots etc.). But if you require to know who did a certain WorldEdit operation and this lags your server you should consider lowering the //blocks// (and //blocks-vip//) value or/and increasing the //interval// value. In general increasing the //interval// value is a better option if your server lags because of disk access issues.

=== Block access controllers === The block access control is handled through my other plugin http://dev.bukkit.org/bukkit-plugins/blockshub/. Through it all block place events are forwarded to block access control plugins. Although I did not notice server lag caused by this feature your configuration might by different. If you are doing large edits that consist of milions of blocks and your CPU is almost maxed out this might cause your server to lag. If this is the case you should disable block access control in the config file (//checkAccess//).

If your server does not require block access control (WorldEdit is not available to all players) or you are using world edit only on PlotMe worlds (plot me handles block access much differently and it work right out of the box without the block access control enabled) you don't need to enable this function. Although if you are running an open creative world that has safe zones you should consider using this option.

== Client side lag == Although your server may not experience TPS drop your players might experience client side lag. Those lags are caused by chunk updates being send to the client. Chunk updates can cause the client to lag or even crash because of high bandwidth usage or high CPU usage. You can try reducing the client side lag by increasing the //interval// value in the config file. The higher this value gets the less often AWE edits the world therefore the chunks get updated less. You could also play with the //blocks// and //blocks-vip// value.

== Quick tips: ==

Try lowering the //blocks// and //blocks-vip// value

Try increasing the //inteval// value

Do not allow queue size bypass in perms!

Lower the maximum amount of blocks the players are allowed to place (//queue-limit-hard// and //queue-limit-soft//)

Disable block loggers (//logBlocks//)

Disable block access control (//checkAccess//)

Try to get more free memory on the server (either by disabling features or by adding more RAM)

Get a faster CPU