AsyncWorldEdit - What performance you may expect

Discussion in 'Systems Administration' started by Weby, Mar 25, 2015.

  1. i would recommend leaving the area so all chucks the worldedit is in will unload, that way it stops updating light.

    my bps is around 10000 when in the area watching it.
    When i leave the area, so all chucks unloads it will shoot up to 5-60000, sometimes around 100000 bps, but then you will not have light updates :p

    Also another thing that may slow your bps is a block logger, i use logblock, and when i do /lb hide (a command so logblock no longer logs my blocks or worldedit) it will go from 10000 to around 2-30000 bps, that combined with leaving the chunks, and i can get about 160000 bps on a good day
     
    • Like Like x 1
  2. Sorry it has taken such a long time to get back to you; been quite busy with things. Anyway here is my config:
    Code (Text):
    awe:
      #Do not change
      version: 3
      rendering:
        #amount of time (in ticks) the server will place a chunk of blocks
        interval: 10
        #how often that a user will get an update on the current que (number of intervals)
        talk-interval: 10
        #maximum size of the blocks queue
        queue-max-size: 1000000000
      dispatcher:
        #maximum number of jobs performed in one run
        max-jobs: 4000
        #maximum number of idle runs before disabling the dispatcher
        max-idle-runs: 200
        #maximum number of miliseconds the dispatcher can use
        #This value should be lower than 50% of 1 tick (25ms)
        max-time: 20
      #Maximum number of blocks in que mode before AWE forces block placing.
      #Use -1 to disable force flush.
      forceFlushBlocks: -1
      #Check for updates
      checkVersion: true
      #Disable or enable blocks physics freeze when placing blocks
      physicsFreez: true
      #File containing all the messages
      strings: "english.yml"
      #Show debug messages
      debug: false
      #Blocks hub plugin options
      blocksHub:
        #Enable block chang loggin
        logBlocks: false
        #Enable blocks access control
        checkAccess: false
      #Player permission groups.
      #Permission node: AWE.Groups.<group name>
      permissionGroups:
        #The group entry (at least one group is required!)
        #If a player has multiple groups, the last one defined in the config
        #is assigned. (Lower the group the lower the 'weight' if you can compare it to PEX)
        default:
          #Indicates that the group is called default.
          #Only one group can be default, if multiple groups are set to default
          #the first one is used as default. The default group is used for players
          #that do not have any other permission groups assigned to them.
          isDefault: true
          #Maximum number of jobs a player can have. -1 = no job limit
          maxJobs: -1
          #Enable or disable auto job cancelation on player quit
          cleanOnLogout: true
          #Default AWE status for loging in players
          defaultMode: on
          renderer:
            #blocks to place (per-interval), this determines the max speed of block placing
            #if you experience lag lower this and the next number (time), use -1 for no limit
            blocks: -1
            #Maximum number of miliseconds spend on placing blocks, use -1 for no limit
            time: -1
          queue:
            #maximum size of the player block queue
            limit-hard: -1 #500000
            #number of blocks on the player queue when to stop placing blocks
            limit-soft: -1 #250000
          messages:
            #Whether or not to show progress using BarAPI
            progress-bar: true
            #Whether or not to show progress using the chat messages
            progress-chat: true
            #is async world edit talkative
            talkative: true
    #Example of additional vip group:
    #    vip:
    #      #you can remove this, the isDefault is by default set to false
    #      isDefault: false
    #      maxJobs: -1
    #      cleanOnLogout: false
    #      #You can omit entries with that are same value as in the default group
    #      #defaultMode: on
    #      renderer:
    #        blocks: 20000
    #        time: -1
      #AWE will make the following WorldEdit actions async
      enabledOperations:
        - undo
        - redo
        - fillXZ
        - removeAbove
        - removeBelow
        - removeNear
        - setBlocks
        - replaceBlocks
        - makeCuboidFaces
        - makeCuboidWalls
        - overlayCuboidBlocks
        - naturalizeCuboidBlocks
        - stackCuboidRegion
        - moveCuboidRegion
        - drainArea
        - fixLiquid
        - makeCylinder
        - makeSphere
        - makePyramid
        - thaw
        - simulateSnow
        - green
        - makePumpkinPatches
        - makeForest
        - makeShape
        - deformRegion
        - hollowOutRegion
        - paste
        - copy
        - cut
        - regenerate
        - center
        - drawLine
        - drawSpline
        - makeBiomeShape
        - forest
        - flora
        - setBiome
        - loadSchematic
        - saveSchematic
        - craftScript
        - makeFaces
        - makeWalls
        - overlayBlocks
        - naturalizeBlocks
        - stackRegion
        - moveRegion
     
    Will
     
  3. Is there some guide to tuning the free version? I'm using the default config, and I feel my server can do better. Which parameter(s) do I start modifying first?
     
  4. Play around with the various limits and intervals. There really isn't a guide since these values can increase RAM or CPU usage. E.g. decreasing the first interval node will make block placing occur faster. Increasing time under render gives AWE more time to spend attempting to place blocks in each interval.
     
    • Agree Agree x 1
  5. Please don't take this the wrong way, but if I told my boss I was going to "play around" with some system settings to see if I could get the system to work better, he would be questioning my competence.

    EDIT: So help me out here. Can someone walk through how AWE does its processing in relation to the various timing and queue size parameters? Maybe we could develop a guide to adjusting performance.

    EDIT II: At least explain the difference between rendering.interval and renderer.time
     
    #25 Bobcat00, Apr 18, 2016
    Last edited: Apr 18, 2016
  6. Honestly there's no other way to do this other than perhaps testing on similar specs of your own. It's all up to how many jobs you wish to have occurring concurrently, and the specs of the machine. I know SB_Prime has some results regarding max queue size for RAM, but that's the only metric I know of.
    There really isn't much more to what I said
    But I guess I could reword it:

    AWE will place blocks every interval ticks. AWE will spend a maximum of time to place blocks during a "block place" tick. Thus you can have the actual block placing occur faster by decreasing interval, while having more blocks placed per "interval" tick by increasing time.
     
    • Agree Agree x 1
  7. OK, good. So the default settings are interval = 15 ticks = 750 msec, and time = 75 msec. So that's the maximum duty cycle, in this case 10%.

    So when does AWE pause in it's block placing? When it hits the 'time' limit. When else? The 'blocks' limit? So with the default values, AWE will place blocks for 75 msec or until it places 10,000 blocks, whichever comes first?

    Also, is the block placing on the main thread or an async thread? I ask because it's interesting that the default time limit is more than 1 tick.
     
    #27 Bobcat00, Apr 18, 2016
    Last edited: Apr 18, 2016
  8. It will pause every 14/15 ticks (not sure, didn't look at code), on the 15th tick it will place blocks. Then it'll wait another 14/15 ticks before placing another batch.
    Yes.
    Block placing is in main thread. It only happens in one tick (as re-explained in my first answer in this post).
     
    • Agree Agree x 1
  9. OK, so that explains why SBPrime says to limit the 'time' to 100 msec maximum. That would be two full ticks.

    I'm placing 5000 block/sec with an 'interval' of 750 msec. That's 3750 blocks in each interval. So if I wanted to try a duty cycle of 25% (my server is lightly loaded), I could leave the 'time' at 75 msec and lower the interval to 6 ticks = 300 msec (75/300=25%). That should get me up to 12,500 blocks/sec. EDIT: I should also set the talk-interval to 15.

    I'll have to try this out. See, there are better ways than just "playing around" with the numbers! I've been doing this type of work for over 35 years.
     
    #29 Bobcat00, Apr 18, 2016
    Last edited: Apr 18, 2016
  10. So I tested with a volume of 101x50x101 (500k blocks) on a plot world starting at y=64. By making the changes above, I was easily able to place 30,000 blocks/sec. I then set up a separate group so regular users would be limited to 5,000 blocks/sec.

    The problem I had was I could run the server out of memory and crash it by repeatedly doing //set commands. I assume this is WorldEdit's undo buffer. What's the best way to limit the size of that? I changed WorldEdit's config history.size from 15 to 3. My plot world has 101x101 plots, so users can select a lot of blocks.
     
  11. My boss has nothing gains me playing with the config as long as its not worse. Before changing anything we ALWAYS do the tests on a test machine then on production.

    You can read the max queue size on github:
    https://github.com/SBPrime/AsyncWorldEdit/wiki "How many blocks can I queue?"

    For configuration description check:
    https://github.com/SBPrime/AsyncWorldEdit/wiki/Configuration

    Exactly, AWE can place max 10k blocks or place them for up to 75ms. It also stops placing blocks when the queue runs out of blocks.

    All AWE operations are divided into 2 stages:
    1. Calculate the blocks that are going to be changed and queue them -> fully async, sometimes AWE needs to use the dispatcher
    2. Place blocks using MainThread
    The default time is set to more then 1 tick intentionally. I figured out that its better to have a higher BPS and loos 1tick then keeping it hard on 20tps.

    This is how often AWE tells the player how many blocks it has and whats the BPS.

    True but you need to remember that the block placing speed depends on what you are placing and where. If block placing causes light recalculation (for example placing blocks over void) your BPS will drop down drastically. That's why I do not suggest disabling the time limit.

    I think by play around @RoboMWM meant that you need to figure out what works best for you. Not to change them randomly. When you decrease the interval you still need to test it what works best for your setup.

    Please remember that each group is treated individually so if you have 3 groups, and all groups have time set to 50ms you might use up to 3ticks! This was changed in the premium version, the groups share the time and block count.

    You are probably right. It can also happen if you set up a to large AWE queue.

    There is no good solution for this. You could force clearhistory for players and/or limit the number of changed blocks. You could also try to do save world + force GC when you detect memory low. The premium version tracks the memory usage and pauses (or cancels dipending on the config) all WE/AWE operations when low memory is detected. It also stores the WE undo on disk (this feature is in beta and some bugs need to be fixed).
     
  12. OK, thanks! "Playing around" is different from "experimenting". The latter requires an understanding of how the parameters work and interact with each other. That's why I'm asking these questions. :) (I have read the help info on the web site.)

    Some questions about the queue size limits: queue-max-size, limit-hard, limit-soft, and forceFlushBlocks. Does limit-hard actually prevent the user from doing WorldEdits which exceed that amount? Or does it simply pause? How much memory does each block need? And what about forceFlushBlocks? Maybe the best thing would be to just do a brief walkthrough of what happens when an operation is started.
     
  13. No that's what I meant, to experiment with different values.
    queue-max-size is a server-wide limit. Limit-hard is an absolute max limit for how much the a single player can queue; I can't entirely recall what happens when you hit the limit; can't remember if it just stopped queuing until more blocks have been placed or what. As for memory: https://github.com/SBPrime/AsyncWorldEdit/wiki#how-many-blocks-can-i-queue

    If you want to restrict the amount of blocks a user can WE, the WE config has its own limits you can use.
     
  14. Same schematic, same hardware using AsyncWorldEdit Premium:


    Block placing speed: 2 500 000 blocks per second.
     
  15. Please can you post the config you are using for this? as I can't paste anything that quickly and I am on a 6gm server. Also mine is pasting in little lines, not all at once like yours did
     
    1. The config is set to default
    2. I'm using the premium version of AWE
    3. I'm using the /chunk paste command
     
  16. I have those settings and I am using AWE Premium, however when I tried using chunk paste and I get this error "Invalid coordinates specified."
    I've tried loads of things to get round it but nothing seems to work, any ideas?
     
  17. Do not do "//chunk paste" do "/chunk paste"
     
  18. Sorry for being a pain, but now when I do "/chunk paste" I just get unknown command, what version of world edit are you using?
     
  19. You need AsyncWorldEdit premium do to chunk commands.