1. Guest, as per the stickied thread, this forum has not been in use since 2014. All bugs and feature requests should be posted to JIRA.

Solved PlayerConnection.sendPacket performance issue?

Discussion in 'Bugs & Feature Requests' started by bergerkiller, Apr 15, 2013.

  1. This is actually more of a task.

    PlayerConnection.sendPacket, unlike on CraftBukkit, directly calls the Netty channel.write. When profiling, I noticed that a lot of time was wasted on this method, and it showed up in NoLagg Chunks for that reason. I am talking about around 1 ms/invocation average, usually more than that.

    Some other server developers need to profile the PlayerConnection.sendPacket and try to optimize it's performance. Previously a simple queue was used, and then it was sent. For some reason, the queueing in Netty is inactive or useless, because it still takes far too long to write data for the caller.

    Profiler screenshot:
    [​IMG]

    NoLagg Chunks chunk sending task (all roads lead to sendPacket):
    [​IMG]

    Also: notice the spikes: that is when I move around and change chunks, and NoLagg starts sending chunks. Times in between are idle times.

    As some have said on IRC: sendPacket shouldn't even be in the ms range. However, profiling both using a profiler and some System.nanoTime calls tell a different story.

    The processing times are random, and appear to slightly depend on the type of packet. Most MS time is lost because of MapChunkBulk packets being sent (which is why the chunk sending task in NoLagg Chunks shows up as high as it does). For map chunk sending, I measured the execution time using System.nanoTime(). It ranged from 0.5 ms to 7 ms.

    Don't take my word for it, please, profile it for yourself and see how well things are behaving. But considering sendPacket is called so often on live servers with > 10 players, this could become an issue.
     
    #1 bergerkiller, Apr 15, 2013
    Last edited: Apr 15, 2013
    • Informative Informative x 1
  2. md_5

    Administrator Developer

    Addressed with the new packet sending / queuing.