Apache AWF
  1. Apache AWF
  2. AWF-169

Optimized ByteBuffer usage in AsynchronousSocket

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      The ByteBuffer usage is HttpProtocol is pretty optimized (bytebuffer reusage etc). Apply the similiar usage in AS

        Activity

        Hide
        Ulrich Stärk added a comment -

        Before we start with the optimization it makes probably sense to create a set of benchmarks that exercises the AS, so we can track the changes...

        Show
        Ulrich Stärk added a comment - Before we start with the optimization it makes probably sense to create a set of benchmarks that exercises the AS, so we can track the changes...
        Hide
        Roger Schildmeijer added a comment - - edited

        Currently we allocate (malloc (relatively slow) + memset (fill with zeros, fast)) a new BB everytime we receive the handleRead callback.

        Proposal: At the end of the first handleRead callback we could attach the "used" (and newly allocated) bb on the SelectionKey, and have an if statement like:

        if (key.attachment() != null)

        { reuse the attached bb}

        The reuse would eliminate the execessive allocating of new byte buffers (atleast to some extent. a byte buffer pool could be next step forward)

        Show
        Roger Schildmeijer added a comment - - edited Currently we allocate (malloc (relatively slow) + memset (fill with zeros, fast)) a new BB everytime we receive the handleRead callback. Proposal: At the end of the first handleRead callback we could attach the "used" (and newly allocated) bb on the SelectionKey, and have an if statement like: if (key.attachment() != null) { reuse the attached bb} The reuse would eliminate the execessive allocating of new byte buffers (atleast to some extent. a byte buffer pool could be next step forward)
        Hide
        Julien Vermillard added a comment -

        I'm agree with Ulrich, this kind of optimization are difficult to know if they are pertinent without benchmarking. In mina we was pooling buffer and trying to use direct buffer but we finally discovered the JVM was doing better on his own.

        Show
        Julien Vermillard added a comment - I'm agree with Ulrich, this kind of optimization are difficult to know if they are pertinent without benchmarking. In mina we was pooling buffer and trying to use direct buffer but we finally discovered the JVM was doing better on his own.
        Hide
        Roger Schildmeijer added a comment -

        Ulrich's comment is actually mine (Roger Schildmeijers) (the initial github to jira migration scripts was ran by Ulrich)

        Interesting. Thanks for the information. Might come back to you regarding this, if its ok?

        Show
        Roger Schildmeijer added a comment - Ulrich's comment is actually mine (Roger Schildmeijers) (the initial github to jira migration scripts was ran by Ulrich) Interesting. Thanks for the information. Might come back to you regarding this, if its ok?
        Hide
        Julien Vermillard added a comment -

        heh ok

        The test are quite old, I think it's interesting to benchmark buffers & pooling again with deft.
        Here you have pointer to the details : https://issues.apache.org/jira/browse/DIRMINA-323

        Show
        Julien Vermillard added a comment - heh ok The test are quite old, I think it's interesting to benchmark buffers & pooling again with deft. Here you have pointer to the details : https://issues.apache.org/jira/browse/DIRMINA-323
        Hide
        Emmanuel Lecharny added a comment -

        As Julien mentionned, pooling BB would put a strain on the JVM, simply because this pool will have to be synchronized to some extent. The JVM GC does a way better work at providing newly allocated blocks of data taken from a pool.

        Regarding the Direct/heap buffer, when we did some experiments 3 years ago, HeapBuffer were way less expensive to create. We have had a discussion with Seven this week, it seems that in Java 7, this is not the same story. It would be interesting to conduct some tests with the new JVM.

        Show
        Emmanuel Lecharny added a comment - As Julien mentionned, pooling BB would put a strain on the JVM, simply because this pool will have to be synchronized to some extent. The JVM GC does a way better work at providing newly allocated blocks of data taken from a pool. Regarding the Direct/heap buffer, when we did some experiments 3 years ago, HeapBuffer were way less expensive to create. We have had a discussion with Seven this week, it seems that in Java 7, this is not the same story. It would be interesting to conduct some tests with the new JVM.

          People

          • Assignee:
            Unassigned
            Reporter:
            Niklas Gustavsson
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development