https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-889 netconf <p>The decoding performance of DelimiterBasedFrameDecoder, and hence the performance of NetconfEOMAggregator extending DelimiterBasedFrameDecoder becomes the bottleneck of NETCONF channel pipeline when small increments of a long frame are processed. For example, fetching YANG schema files (total 22 MB) from Juniper MX2020 takes about 16 minutes.</p> <p>The main reason for this poor performance is because <a href="https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/handler/codec/DelimiterBasedFrameDecoder.java#L314" class="external-link" target="_blank" rel="nofollow noopener">delimiter search starts over from the beginning of the frame (readerIndex)</a> for each decode call in the indexOf method.</p> NETCONF-889

Improve EOM aggregator performance

Improvement High Resolved Done Sangwook Ha Sangwook Ha Mon, 11 Jul 2022 18:06:23 +0000 Mon, 31 Oct 2022 12:44:32 +0000 Fri, 29 Jul 2022 10:42:40 +0000 4.0.0 3.0.6 2.0.17 netconf 0 2 <p>So there is a pre-existing patch for this.</p> <p>I also wonder if it would not make sense to also push a fix for Netty.</p> <p>Right, I found that out after submitting a change. The idea is the same, just difference in keeping track of progress.<br/> One thing I wonder, for both changes, is whether it's robust enough to handle change in ByteBuf allocation, which I think should happen in one way or another because the index cannot increase forever.</p> <p>There was an issue with change 75490 as suspected - it fails to process a case where ByteBuf is updated with readerIndex reset to 0.<br/> I fixed the issue and pushed a <a href="https://git.opendaylight.org/gerrit/c/netconf/+/75490/5" class="external-link" target="_blank" rel="nofollow noopener">new patch set</a> with another test case and some cleanup.<br/> <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a>, please take a look.</p> Development Rank 0|i042mv: