From: Tony Arcieri <tony@...>
Date: 2007-02-24T03:11:15+09:00
Subject: Re: Stateful I/O interface

------=_Part_39541_13771695.1172254272141
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm looking primarily for scalability improvements in terms of handling
higher numbers of concurrent connections.  It's definitely something where
any implementation would need to be benchmarked to determine if it's
actually useful.

-- 
Tony Arcieri
ClickCaster, Inc.
tony@clickcaster.com

On 2/22/07, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
>
> On 2/22/07, Tony Arcieri <tony@clickcaster.com> wrote:
> >
> >
> > I'm thinking of putting together a quick patch would provide basic epoll
> > support through my suggested interface.  Would that be helpful in evaluating
> > this idea?  I could also write a small benchmarking program to compare
> > Kernel#select performance to a stateful interface.
> >
>
>
> One question for you (I may have already asked you this, if so, I
> apologize): what are your success metrics for an epoll implementation? Why
> do you actually need it? Are you looking for performance improvements, an
> improvement in scalability (breaking the 1024-descriptor limit), or
> something else. When I did a (non-published) epoll version of EventMachine,
> I was surprised to find that it wasn't measurably faster than the
> select-based implementation. I think this is because the performance profile
> of an EM program is so dominated by the ruby glue and by user-supplied ruby
> code that making the raw I/O faster just won't be that noticeable.
>
>

------=_Part_39541_13771695.1172254272141
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I&#39;m looking primarily for scalability improvements in terms of handling higher numbers of concurrent connections.&nbsp; It&#39;s definitely something where any implementation would need to be benchmarked to determine if it&#39;s actually useful.
<br><br>-- <br>Tony Arcieri<br>ClickCaster, Inc.<br><a href="mailto:tony@clickcaster.com">tony@clickcaster.com</a><br><br><div><span class="gmail_quote">On 2/22/07, <b class="gmail_sendername">Francis Cianfrocca</b> &lt;<a href="mailto:garbagecat10@gmail.com">
garbagecat10@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="q">On 2/22/07, <b class="gmail_sendername">
Tony Arcieri</b> &lt;<a href="mailto:tony@clickcaster.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tony@clickcaster.com</a>&gt; wrote:</span><div><span class="q"><span class="gmail_quote"></span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span>&nbsp;</span><br><div><div>I&#39;m thinking of putting together a quick patch would provide basic
epoll support through my suggested interface.&nbsp; Would that be helpful in evaluating this idea?&nbsp; I could also write a small benchmarking program to compare Kernel#select performance to a stateful interface.</div></div></blockquote>

</span><div><br><br>One question for you (I may have already asked you this, if so, I apologize): what are your success metrics for an epoll implementation? Why do you actually need it? Are you looking for performance improvements, an improvement in scalability (breaking the 1024-descriptor limit), or something else. When I did a (non-published) epoll version of EventMachine, I was surprised to find that it wasn&#39;t measurably faster than the select-based implementation. I think this is because the performance profile of an EM program is so dominated by the ruby glue and by user-supplied ruby code that making the raw I/O faster just won&#39;t be that noticeable.
<br></div><br></div>
</blockquote></div>

------=_Part_39541_13771695.1172254272141--