You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Nikita Vetoshkin (JIRA)" <ji...@apache.org> on 2012/12/03 08:53:58 UTC

[jira] [Updated] (ZOOKEEPER-1595) Sockets should be read until exhausted

     [ 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