Loading ...
Sorry, an error occurred while loading the content.
 

Server architecture

Expand Messages
  • Shane Kerr
    FTP Bencharoos, I don t know if everybody has already seen this or not, but the following article on benchmarking various OS s is somewhat interesting in the
    Message 1 of 2 , Jun 21, 2001
      FTP Bencharoos,

      I don't know if everybody has already seen this or not, but the
      following article on benchmarking various OS's is somewhat interesting
      in the good description of the various server software architectures:

      http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm

      I thought the following graphic was particularly telling:

      http://www.sysadminmag.com/articles/2001/0107/0107a/0107a_f3.htm

      It claims the asynchonous model can handle about 35% more load than the
      multithreaded model. Note that "asynchronous" in this context means
      "select/poll", not POSIX asynchronous IO - which we would expect to be
      more effecient under extremely heavy load (more than 1000 simultaneous
      connections).

      Shane
    • Dan Kegel
      ... I read the article, and got turned off by their incorrect terminology and by the fact that they ignored things like Solaris s /dev/poll, Linux s realtime
      Message 2 of 2 , Jun 21, 2001
        Shane Kerr wrote:
        > FTP Bencharoos,
        >
        > I don't know if everybody has already seen this or not, but the
        > following article on benchmarking various OS's is somewhat interesting
        > in the good description of the various server software architectures:
        >
        > http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm
        >
        > I thought the following graphic was particularly telling:
        >
        > http://www.sysadminmag.com/articles/2001/0107/0107a/0107a_f3.htm
        >
        > It claims the asynchonous model can handle about 35% more load than the
        > multithreaded model. Note that "asynchronous" in this context means
        > "select/poll", not POSIX asynchronous IO - which we would expect to be
        > more effecient under extremely heavy load (more than 1000 simultaneous
        > connections).

        I read the article, and got turned off by their incorrect terminology
        and by the fact that they ignored things like Solaris's /dev/poll,
        Linux's realtime signal-based i/o, and FreeBSD's kqueue call.
        I know for a fact that FreeBSD using kqueue can handle several orders of
        magnitude more network connections than the authors of that article achieved,
        so this isn't a minor quibble.

        One has to wonder whether the authors have seen http://www.kegel.com/c10k.html,
        it doesn't sound like it.

        But hey, it was interesting data anyway.
        - Dan
      Your message has been successfully submitted and would be delivered to recipients shortly.