[
https://issues.apache.org/jira/browse/ZOOKEEPER-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Vetoshkin updated ZOOKEEPER-1595:
----------------------------------------
Summary: Sockets should be read until exhausted (was: Socket's should be
read until exhausted)
> Sockets should be read until exhausted
> --------------------------------------
>
> Key: ZOOKEEPER-1595
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1595
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Environment: Tested on Linux x64 with Oracle JDK6
> Reporter: Nikita Vetoshkin
> Priority: Minor
> Labels: newbie, performance
> Attachments: read_write_until_exhausted.patch
>
>
> {{doIO}} method in {{NIOServerCnxn}} should read (and write too) until
> {{read}}/{{write}} returns 0.
> It's a common practice when working with non-blocking sockets. When an
> underlying system call (multiplexer) signals, that socket is readable, one
> should {{recv(2)}} all data from kernel buffer until {{recv}} fails with
> {{EAGAIN}} or {{EWOULDBLOCK}}.
> Patch does two things (I know it's not a good idea to mix several changes,
> but I could stand it):
> * splits {{doIO}} into {{doRead}} and {{doWrite}}
> * wraps reading with {{while (true)}}
> It's pretty easy to instrument code with a counter and print how many loops
> we performed until the socket was not readable again.
> I wrote a simple python script (http://pastebin.com/N5ifM330) which creates
> 6000 nodes with 5k data each, having 20 concurrent create requests in
> progress through one connnection.
> With this script and strace attached to JVM I counted epoll_wait syscalls
> during the test and I got ~9500 before vs ~8000 after.
> Run time measurement is very rough, but it's around ~19 secs. before vs 17.5
> after.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
