I noticed EM appears to not actually send any data when you do send_data. It instead queues it, then waits for the next (readable) cycle and then sends data. This has the advantage of coalescing tiny messages into larger ones. But also might slow things down a tidge. Thoughts? Thanks! -=R
On Fri, Sep 5, 2008 at 3:34 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> I noticed EM appears to not actually send any data when you do > send_data. It instead queues it, then waits for the next (readable) > cycle and then sends data. This has the advantage of coalescing tiny > messages into larger ones. But also might slow things down a tidge. > Thoughts?Originally I tried to have Rev send immediately if there was no data in the output buffer. I ran into problems with event loop starvation and so forth, and opted to have it buffer first then write if the socket is writable. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080905/a798dc12/attachment.html>
On Fri, Sep 5, 2008 at 4:05 PM, Tony Arcieri <tony at medioh.com> wrote:> On Fri, Sep 5, 2008 at 3:34 PM, Roger Pack > <roger.pack at leadmediapartners.com> wrote: >> >> I noticed EM appears to not actually send any data when you do >> send_data. It instead queues it, then waits for the next (readable) >> cycle and then sends data. This has the advantage of coalescing tiny >> messages into larger ones. But also might slow things down a tidge. >> Thoughts? > > Originally I tried to have Rev send immediately if there was no data in the > output buffer. I ran into problems with event loop starvation and so forth, > and opted to have it buffer first then write if the socket is writable.How was starvation caused, do you think? -=R
On Fri, Sep 5, 2008 at 5:03 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> How was starvation caused, do you think? >It was a case of callbacks that kept mutually calling each other and bypassing the reactor core entirely. I don''t entirely remember what the exact circumstances are, but by not doing the write immediately you ensure at least one pass through the reactor before a write is attempted and any callbacks are fired. It may not be entirely applicable to EM, but I wouldn''t be surprised if Francis ran into a similar problem. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080905/fadbf427/attachment.html>
> It was a case of callbacks that kept mutually calling each other and > bypassing the reactor core entirely. I don''t entirely remember what the > exact circumstances are, but by not doing the write immediately you ensure > at least one pass through the reactor before a write is attempted and any > callbacks are fired.So was this a loop involving on_write_complete [which would make sense]?
On Fri, Sep 5, 2008 at 8:03 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> So was this a loop involving on_write_complete [which would make sense]? >I can''t remember, but that''d certainly be one of the places where you''d expect it to happen -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080905/46b5fe5c/attachment.html>
If that''s the case another option might be to run through and write to all sockets writable sockets, THEN do reads from all readable sockets [with the associated callbacks]. Of course, I''m trying to fix a problem that I don''t even know exists LOL. Maybe the savings for this kind of tweak are pretty much nil compared with the overhead rails adds to the picture anyway, but I''m just afraid that if you have too many sockets that select readable that you''ll kind of starve out your writable sockets. Again I''m not really sure if this is a real problem or not, or is round robin just cleaner? Thoughts? -=R On Fri, Sep 5, 2008 at 5:03 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> On Fri, Sep 5, 2008 at 4:05 PM, Tony Arcieri <tony at medioh.com> wrote: >> On Fri, Sep 5, 2008 at 3:34 PM, Roger Pack >> <roger.pack at leadmediapartners.com> wrote: >>> >>> I noticed EM appears to not actually send any data when you do >>> send_data. It instead queues it, then waits for the next (readable) >>> cycle and then sends data. This has the advantage of coalescing tiny >>> messages into larger ones. But also might slow things down a tidge. >>> Thoughts? >> >> Originally I tried to have Rev send immediately if there was no data in the >> output buffer. I ran into problems with event loop starvation and so forth, >> and opted to have it buffer first then write if the socket is writable. > > How was starvation caused, do you think? > > -=R >-- Thanks! -=R