<forwarding to the dev_at_grizzly>
Hello Ramesh,
I agree with your comments and findings about UDP.
UDP is really different than TCP, I mean NIO implementation, so,
agree, we should behave different way in UDPSelectorHandler than we do
for TCP.
Your proposal is interesting, however, IMHO, there is sensitive
drawback... Until message will not be read from channel - OP_READ op.
will always occur on SelectionKey. It means that while we will not
read the message in a worker thread - a selector thread will loop with
ready OP_READ operation, which is not good.
Sometimes I had an idea on improving the UDP, but never had time to
experiment and implement something reasonable.
It could be interesting to try the UDP transport implementation, where
reading is happening in the selector thread, and then selector thread
forwards control to a worker thread.
From one side this could cause bottleneck, because the read operation
will take a lot of time and other UDP channels, which are registered
on the same selector will wait. And we will need to create more
Selector threads, than was usually used for TCP. From other side, if
we have just UDP server scenario, where all messages from different
clients come on the same UDP channel - this can sensitively improve
the perf. numbers, because there will be no double thread context
switch between reads.
I'll really appreciate, if you can experiment with solution above, so
we can see some numbers.
Thank you.
WBR,
Alexey.
On Aug 29, 2008, at 10:10 , Ramesh Parthasarathy wrote:
> Hi Alexey,
> I was doing some load testing with UDP, and found that its
> considerably less performant than the TCP path.
> Especially because reading and processing of every UDP datagram
> involves registering the READ and a selection process. Basically we
> are reading the messages serially one after the other from the
> listener, perhaps the performance degradation (compared to TCP)
> would not be much if each datagram were bigger in size (bigger than
> standard SIP message). But for smaller datagrams (4K) this process
> of reading the datagrams one by one (which involves the selector) is
> kind of slow.
>
> Unlike TCP its not necessary to wait untill the bytes have been
> read , to register back the read key. We could basically keep the
> READ op in the interestOps always, dont have to remove it at all.
>
> This is because the javadoc for receive says
>
> "The datagram is transferred into the given byte buffer starting at
> its current position, as if by a regular read operation. If there
> are fewer bytes remaining in the buffer than are required to hold
> the datagram then the remainder of the datagram is silently discarded"
>
> So there is no question of a thread requiring more data than what it
> got after the first receive operation.
>
> And also "This method may be invoked at any time. If another thread
> has already initiated a read operation upon this channel, however,
> then an invocation of this method will block until the first
> operation is complete."
>
> the above essentially guarantees that 2 workerthreads cannot operate
> on the channel simultaneously.
>
> Considering the above, I was wondering if we could modify the
> UDPSelectorHandler and override the onReadInterest and remove the
> code which removes the READ op from the interest ops. This way a
> READ is always registered on a UDP channel/socket. I am currently
> testing a version where i have extended the UDPSelector and
> overrided the ReadInterest method.
>
> Please let me know your thoughts, and also if you have any other
> idea for bettering the UDP performance.
>
> Thanks
> -Ramesh
>
>
>
>