|
I've checked the way those PDU are created, and I think that the best place to merge the chunks could be in the encoder. Actually, every Tuple generates a ByteBuffer and push it on a stack, which is sent by MINA. An encoder that merge all those little chunks could help to improve this behavior.
Of course, for very large PDU like Search results, we will have to deal with the memory footprint in the same way we should do it for the decoding process. I agree Trustin re: changes to encoder. This is something we should factor into a redesign making sure the encoder decoder line up with MINA for maximum performance gains.
A workaround that merge the chunks. It seems to work, I still have to evaluate the performance impact of this modification.
I repeat : it's nothing else but a workaround. It's ugly... +1 for a modification at the decoder level, but it will be a lot of work ...
Emmanuel Lecharny made changes - 09/Mar/05 08:16 AM
Look why don't we just rewrite this thing top to bottom with this consideration in mind. Let's hand write the LDAP codec with all the optimizations making sure its as fast as lightning and fits into MINA like a hand in a glove.
I've written and re-written this code in
other products. Some random thoughts: Encode the bits in-place. That is, where you have an entry for a search result in your hand, go call whatever code generates the BER, right there. Accumulate the BER bits in a buffer, do not attempt to send immediately, unless the buffer overflows. Do not store some intermediate symbolic representation of the data : just make the BER. This is safe to do because you are always generating BER left to right, and have no need to retrace your steps. Flush the buffer (only) every time you send a response PDU (search result done in the case of a search). This ensures that you coalesce a search entry PDU with the search result done PDU into one TCP segment. Doing this can deliver a significant performance benefit. In some client/server scenarios you will find it beneficial to disable nagle on the TCP session. Don't worry about UDP : nobody uses it. I've done some tests based on the 0.9 Apache DS and the same version with the patch I've attached in a previous comment. Here are both screenshot of the same JMeter run : the un-chunked version has a 5 x times better througput than the original version (only one thread requestiong 1000 times the same thing...).
I agree with Alex and David. Rewritting the whole codec will certainly improve performance a lot. Let's do it, and do it now ! I think that the encoding part is the most important one as it's the one that send search results.
Emmanuel Lecharny made changes - 09/Mar/05 09:11 AM
Hi,
I looked at the patch, and now I realized ApacheDS LDAP encoder generates arrays of ByteBuffers. If it is always like that, we would be able to set up a rule that an array of ByteBuffers are to be merged. So I think merging that patch seems to be OK at all. WDYT? I fixed MINA Asn1Encoder using new mergeAll() method in ProtocolEncoderOutput.
Here's the change I've made: http://svn.apache.org/viewcvs?view=rev&rev=156608 I think it is less efficient in performance than the patch, but it effectively removed duplication of code. The mergeAll has been implemented by Trustin months ago ...
Emmanuel Lecharny made changes - 31/Aug/05 03:18 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Minor
Server PDU are splitted in small chunks
But I'm afraid that Asn1Encoder would not be able to work against UDP because there is a possibility that one message can generate two or more packets and modified version will merge them into one packet. It would be the best if ASN1 codec modify its interface to provide a method that is directly mapped to ProtocolDecoderOutput.mergeAll().
WDYT, Alex?