Is there already a means for benchmarking EM''s performance with various I/O interfaces? I''d like to try adding some stuff to the native extension to allow for a unified bridge to high performance platform-native I/O interfaces and I''d like to see how it performs. -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com (970) 232-4208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/3c8ce751/attachment.html
On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote:> > Is there already a means for benchmarking EM''s performance with various > I/O interfaces? I''d like to try adding some stuff to the native extension > to allow for a unified bridge to high performance platform-native I/O > interfaces and I''d like to see how it performs.No, there isn''t anything like this in the package so far, but I can think of two approaches. First, write up "single-issue" tests to examine such things as number of TCP connections that can be made in unit time to a localhost server, and also to a remote server; raw bytes transferred on a connection; raw throughput across a set of multiple connections (10, 100, 1000); UDP packets transmitted and dropped; and repeat all the TCP tests with SSL. Second, some "real-world" tests designed to assess how the I/O changes will work with real apps. We''d probably need a suite of these, to get confidence over time that the performance-improvement efforts are actually worth the effort. I can imagine a miniature HTTP server and SMTP server. I''m several other folks can suggest tests that match their own applications, too. I can start in building some of the "lab" tests. What would your first priorities be? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/b3abdb40/attachment.html
The biggest priority for me is going to be handling reads and writes from large numbers of TCP connections. On 10/19/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote: > > > > Is there already a means for benchmarking EM''s performance with various > > I/O interfaces? I''d like to try adding some stuff to the native extension > > to allow for a unified bridge to high performance platform-native I/O > > interfaces and I''d like to see how it performs. > > > > No, there isn''t anything like this in the package so far, but I can think > of two approaches. > > First, write up "single-issue" tests to examine such things as number of > TCP connections that can be made in unit time to a localhost server, and > also to a remote server; raw bytes transferred on a connection; raw > throughput across a set of multiple connections (10, 100, 1000); UDP packets > transmitted and dropped; and repeat all the TCP tests with SSL. > > Second, some "real-world" tests designed to assess how the I/O changes > will work with real apps. We''d probably need a suite of these, to get > confidence over time that the performance-improvement efforts are actually > worth the effort. I can imagine a miniature HTTP server and SMTP server. I''m > several other folks can suggest tests that match their own applications, > too. > > I can start in building some of the "lab" tests. What would your first > priorities be? > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk > >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com (970) 232-4208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/74625673/attachment.html
On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote:> > The biggest priority for me is going to be handling reads and writes from > large numbers of TCP connections.What''s a large number? 1000? Are we talking across the network? (That exercises the kernel TCP buffers but makes for a test that''s harder to build with Ruby''s Unit::Test.) Are you trying to measure total throughput or response time for each particular connection? Is each individual connection in the test carrying more or less the same amount of data as all the others? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/b24ca3d8/attachment-0001.html
Well, perhaps I should introduce you to the project we''re using EventMachine for: http://pdtp.org/ We''re essentially building a streaming version of BitTorrent, using central network regulation. So yes, we''re going to run into the same TCP congestion issues client-side (for which we''ll also be using EM) I''m more concerned about server-side connection scalability and providing a way to scale to thousands (or tens of thousands) of connections, with the server processing various control messages from clients. I''m much more concerned with latency of server response than I am for data throughput out of the server. The server will predominantly send control messages. On 10/19/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote: > > > > The biggest priority for me is going to be handling reads and writes > > from large numbers of TCP connections. > > > > What''s a large number? 1000? Are we talking across the network? (That > exercises the kernel TCP buffers but makes for a test that''s harder to build > with Ruby''s Unit::Test.) Are you trying to measure total throughput or > response time for each particular connection? Is each individual connection > in the test carrying more or less the same amount of data as all the others? > > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk > >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com (970) 232-4208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/3b8d3248/attachment.html
On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote:> > Well, perhaps I should introduce you to the project we''re using > EventMachine for: > > http://pdtp.org/ > > We''re essentially building a streaming version of BitTorrent, using > central network regulation.Awesome project. I''ll think about some benchmarks that reflect these requirements. And now I see the point of using epoll- you''re trying to break through the 1024-descriptor select limit, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061019/bde148fb/attachment.html
Yes, or more than 64 on Windows (ouch), although that won''t be a pressing issue for us awhile as we intend to just use Linux servers On 10/19/06, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 10/19/06, Tony Arcieri <tony at clickcaster.com> wrote: > > > > Well, perhaps I should introduce you to the project we''re using > > EventMachine for: > > > > http://pdtp.org/ > > > > We''re essentially building a streaming version of BitTorrent, using > > central network regulation. > > > > Awesome project. I''ll think about some benchmarks that reflect these > requirements. And now I see the point of using epoll- you''re trying to break > through the 1024-descriptor select limit, right? > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk > >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com (970) 232-4208 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20061020/755199bb/attachment.html