epoll state of the art? - Linux

This is a discussion on epoll state of the art? - Linux ; Greetings, I am starting to implement a socket-based server on Linux, and I would like it to be high-performance. (e.g. able to handle 10,000 simultaneous connections) I am using 2.6.23.8 Obviously, select will not scale that high. Is epoll the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: epoll state of the art?

  1. epoll state of the art?

    Greetings,
    I am starting to implement a socket-based server on Linux, and I would
    like it to be high-performance. (e.g. able to handle 10,000
    simultaneous connections) I am using 2.6.23.8

    Obviously, select will not scale that high.
    Is epoll the way to go?

    Furthermore, I suspect Async network I/O will also be useful in
    achieving this level of scalability. Am I on the right track with
    io_submit? Or do folks just use non-blocking fds? signals?

    It is difficult to tell what is the definitive way to go based on the
    various projects that have been started. (e.g. kevent, signalfd,
    etc...?)

    TIA,
    n8

  2. Re: epoll state of the art?

    n8 wrote:
    > Greetings,
    > I am starting to implement a socket-based server on Linux, and I would
    > like it to be high-performance. (e.g. able to handle 10,000
    > simultaneous connections) I am using 2.6.23.8


    Because you did not mention http://www.kegel.com/c10k.html
    then one must conclude that probably you are not qualified
    to attempt such a project.

    --

  3. Re: epoll state of the art?

    On Sep 15, 5:08*pm, John Reiser wrote:
    > n8 wrote:
    > > Greetings,
    > > I am starting to implement a socket-based server on Linux, and I would
    > > like it to be high-performance. (e.g. able to handle 10,000
    > > simultaneous connections) I am using 2.6.23.8

    >
    > Because you did not mention *http://www.kegel.com/c10k.html
    > then one must conclude that probably you are not qualified
    > to attempt such a project.
    >
    > --


    Nice.
    Actually, I read it in it's entirety, which is what led me to post on-
    line.
    Mr. Kegel did an amazing job compiling various topics.
    However, it is about two years old.
    Many of the links don't even resolve and others appear to be obsolete.
    e.g. his section on kevent takes you to Evgeniy Polyakov's blog, which
    states that the kevent project is "closed", basically due to lack of
    interest.
    Then there is evidence that the project might make a come-back.
    Hence my confusion.

    Anybody else out there in a better mood than Mr. Reiser?

    Regards,
    n8

  4. Re: epoll state of the art?

    On Sep 15, 4:48*pm, n8 wrote:

    > Obviously, select will not scale that high.
    > Is epoll the way to go?


    Yes.

    > Furthermore, I suspect Async network I/O will also be useful in
    > achieving this level of scalability. Am I on the right track with
    > io_submit? Or do folks just use non-blocking fds? *signals?


    No for Linux.

    DS

  5. Re: epoll state of the art?

    On Sep 15, 6:35*pm, David Schwartz wrote:
    > On Sep 15, 4:48*pm, n8 wrote:
    >
    > > Obviously, select will not scale that high.
    > > Is epoll the way to go?

    >
    > Yes.
    >
    > > Furthermore, I suspect Async network I/O will also be useful in
    > > achieving this level of scalability. Am I on the right track with
    > > io_submit? Or do folks just use non-blocking fds? *signals?

    >
    > No for Linux.
    >
    > DS


    Wow, I'm very surprised Linux has not settled on a standard Async IO
    mechanism.

    Thanks for the reply!
    n8

  6. Re: epoll state of the art?

    On Sep 16, 1:20*pm, n8 wrote:

    > Wow, I'm very surprised Linux has not settled on a standard Async IO
    > mechanism.


    It has, it just does not have a high-performance implementation of
    that async I/O mechanism.

    DS

+ Reply to Thread