Hello Guys, I''m reviewing the code for 1.9, and forgot about this when we first spoke on this subject. The current way we stop threads is using Thread#raise to spread StopServer exception, which will not work as expected in 1.9. 1.9 will treat raised exceptions as #kill, like JRuby does, so the worker threads will not finish serving the client and _then_ exiting, but will be kill''ed in the middle of the request. (at the bottom of mongrel.rb): http://mongrel.rubyforge.org/svn/trunk/lib/mongrel.rb According to some docs of Jruby and YARV, we should rely on ''thread safety'' of these methods (including #critical and #kill). Thoughts? btw, merry christmas to everybody! :-D -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Tue, 25 Dec 2007, Luis Lavena wrote:> Hello Guys, > > I''m reviewing the code for 1.9, and forgot about this when we first > spoke on this subject. > > The current way we stop threads is using Thread#raise to spread > StopServer exception, which will not work as expected in 1.9. > > 1.9 will treat raised exceptions as #kill, like JRuby does, so the > worker threads will not finish serving the client and _then_ exiting, > but will be kill''ed in the middle of the request. > > (at the bottom of mongrel.rb): > http://mongrel.rubyforge.org/svn/trunk/lib/mongrel.rb > > According to some docs of Jruby and YARV, we should rely on ''thread > safety'' of these methods (including #critical and #kill).Hum.. could you point where are those docs? Easier ask than search, as you already know them.... Anyway, we can still raising an Exception to it, just to stop the accept thing. But then we can call graceful_shutdown method within stop, and not within the @acceptor thread. Something like this: --- lib/mongrel.rb (revision 919) +++ lib/mongrel.rb (working copy) @@ -307,9 +307,6 @@ Mongrel.log(:error, e.backtrace.join("\n")) end end - graceful_shutdown - ensure - @socket.close # Mongrel.log(:error, "#{Time.now.httpdate}: Closed socket.") end end @@ -349,6 +346,9 @@ if synchronous sleep(0.5) while @acceptor.alive? end + + graceful_shutdown + @socket.close end end How about it?> > btw, merry christmas to everybody! :-DFor you too! Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru }
On Dec 25, 2007 9:05 PM, Filipe <filipe at icewall.org> wrote: [...]> > > > According to some docs of Jruby and YARV, we should rely on ''thread > > safety'' of these methods (including #critical and #kill). > > Hum.. could you point where are those docs? Easier ask than search, as > you already know them.... >infoQ: http://www.infoq.com/news/2007/05/ruby-threading-futures Sasada Koichi post at ruby-core: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/10252 Headius, first quarter of 2007: http://headius.blogspot.com/2007_04_25_archive.html> Anyway, we can still raising an Exception to it, just to stop the accept thing. > But then we can call graceful_shutdown method within stop, and not within the @acceptor > thread. Something like this: >The problem is that raising a exception to another thread (Thread#raise) will not work as expected in different interpreters, but maybe I''m reading the docs wrong.> --- lib/mongrel.rb (revision 919) > +++ lib/mongrel.rb (working copy) > @@ -307,9 +307,6 @@ > Mongrel.log(:error, e.backtrace.join("\n")) > end > end > - graceful_shutdown > - ensure > - @socket.close > # Mongrel.log(:error, "#{Time.now.httpdate}: Closed socket.") > end > end > @@ -349,6 +346,9 @@ > if synchronous > sleep(0.5) while @acceptor.alive? > end > + > + graceful_shutdown > + @socket.close > end > > end >Mmm, need to check, no time right now. I''m bootstrapping ruby 1.9 completely from scratch for mingw (part of the new One-Click Ruby Installer). -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Tue, 25 Dec 2007 19:58:15 -0300 "Luis Lavena" <luislavena at gmail.com> wrote:> Hello Guys, > > I''m reviewing the code for 1.9, and forgot about this when we first > spoke on this subject.Don''t forget to check out Rev while you''re at it: http://rev.rubyforge.org/ :-) -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Dec 26, 2007 4:26 AM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Tue, 25 Dec 2007 19:58:15 -0300 > "Luis Lavena" <luislavena at gmail.com> wrote: > > > Hello Guys, > > > > I''m reviewing the code for 1.9, and forgot about this when we first > > spoke on this subject. > > Don''t forget to check out Rev while you''re at it: > > http://rev.rubyforge.org/ > > :-)Didn''t forgot it, but: "This includes the epoll system call for Linux, the kqueue system call for BSDs and OS X, and the completion ports interface for Solaris." No mention of Windows support or test, even that libev code works with fd and sockets on win32. I''ll check that later, now I need to solve some segfaults in readline extension (for ruby 1.9 mingw32 build). Later guys, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 25, 2007 5:58 PM, Luis Lavena <luislavena at gmail.com> wrote:> Hello Guys, > > I''m reviewing the code for 1.9, and forgot about this when we first > spoke on this subject. > > The current way we stop threads is using Thread#raise to spread > StopServer exception, which will not work as expected in 1.9. > > 1.9 will treat raised exceptions as #kill, like JRuby does, so the > worker threads will not finish serving the client and _then_ exiting, > but will be kill''ed in the middle of the request. > > (at the bottom of mongrel.rb): > http://mongrel.rubyforge.org/svn/trunk/lib/mongrel.rb > > According to some docs of Jruby and YARV, we should rely on ''thread > safety'' of these methods (including #critical and #kill). > > Thoughts? > > btw, merry Christmas to everybody! :-D > -- > Luis Lavena > Multimedia systemsMerry Christmas and happy holidays all!!! Perhaps we should implement a check when Mongrel is loaded which sets a variable based on platform / ruby version for which Thread method to call for stop server handling. Then at the point where we stop threads we can .send() the method stored in the variable. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071226/e8669223/attachment-0001.html
On Dec 26, 2007 11:33 AM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote: [...]> > Merry Christmas and happy holidays all!!! > > Perhaps we should implement a check when Mongrel is loaded which sets a > variable based on platform / ruby version for which Thread method to call > for stop server handling. Then at the point where we stop threads we can > .send() the method stored in the variable. >I''ll suggest that for the time being, we set required ruby version <1.8.6 and do some release. *everybody* is playing with 1.9 and they think is stable, they don''t read the "development release" sticker matz put on it... Argh... I''m getting angry :-P -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 26, 2007 4:01 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote: [...]> > That''s ''cause windows sucks. :-) >Yeah, totally agree, but since I earn money from it... shouldn''t complain too much, isn''t?> Actually, Tony and I mostly just do unix so we haven''t been motivated > to work on it. Thus the reason I said you should check it out since it > might help you on Windows. >Will take a look, this weekend with more spare time :-D -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Wed, 26 Dec 2007 04:31:24 -0300 "Luis Lavena" <luislavena at gmail.com> wrote:> > > > Don''t forget to check out Rev while you''re at it: > > > > http://rev.rubyforge.org/ > > > > :-) > > Didn''t forgot it, but: > > No mention of Windows support or test, even that libev code works with > fd and sockets on win32.That''s ''cause windows sucks. :-) Actually, Tony and I mostly just do unix so we haven''t been motivated to work on it. Thus the reason I said you should check it out since it might help you on Windows. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Dec 26, 2007 9:38 AM, Luis Lavena <luislavena at gmail.com> wrote:> I''ll suggest that for the time being, we set required ruby version <> 1.8.6 and do some release. >Agreed *everybody* is playing with 1.9 and they think is stable, they don''t> read the "development release" sticker matz put on it... >Perhaps branch for 1.9? ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071226/59766a42/attachment.html
On Dec 26, 2007 4:22 PM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:> On Dec 26, 2007 9:38 AM, Luis Lavena <luislavena at gmail.com> wrote: > > > I''ll suggest that for the time being, we set required ruby version <> > 1.8.6 and do some release. > > > > Agreed >The same was commented on ruby-core: define ruby version < 1.9 and > 1.8.2 (since there could exist a 1.8.7 release).> > *everybody* is playing with 1.9 and they think is stable, they don''t > > read the "development release" sticker matz put on it... > > > > Perhaps branch for 1.9? >We should leave trunk for 1.8 and bugfixing and start playing with 1.9 in a branch. We already did a lot of changes in trunk that are not ''release quality'' and some experimental stuff (that shouldn''t be there, for the record). Don''t have enough time to start playing with some ideas (not until weekend), but feel free to branch and play safe ;-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Wed, 26 Dec 2007, Luis Lavena wrote:> On Dec 26, 2007 4:22 PM, Wayne E. Seguin <wayneeseguin at gmail.com> wrote: >> On Dec 26, 2007 9:38 AM, Luis Lavena <luislavena at gmail.com> wrote: >> >>> I''ll suggest that for the time being, we set required ruby version <>>> 1.8.6 and do some release. >>> >> >> Agreed >>+1> > The same was commented on ruby-core: > > define ruby version < 1.9 and > 1.8.2 (since there could exist a 1.8.7 release). > >>> *everybody* is playing with 1.9 and they think is stable, they don''t >>> read the "development release" sticker matz put on it... >>> >> >> Perhaps branch for 1.9? >> > > We should leave trunk for 1.8 and bugfixing and start playing with 1.9 > in a branch.Hey guys, we already have a branch called stable_1-1 - evn used this to generate 1.1.2 . So this can be our stable thing and we can stay playing with trunk...> > We already did a lot of changes in trunk that are not ''release > quality'' and some experimental stuff (that shouldn''t be there, for the > record).Hum... not sure :) Well, we have the logger thing, but besides this I don''t remember any other big change...> > Don''t have enough time to start playing with some ideas (not until > weekend), but feel free to branch and play safe ;-) >Welcome back to the party! Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru }
On Wed, 26 Dec 2007, Luis Lavena wrote:> On Dec 25, 2007 9:05 PM, Filipe <filipe at icewall.org> wrote: > [...] >>> >>> According to some docs of Jruby and YARV, we should rely on ''thread >>> safety'' of these methods (including #critical and #kill). >> >> Hum.. could you point where are those docs? Easier ask than search, as >> you already know them.... >> > ... (links)Thanks for the links :) Well, one important note from ko1 in one of those links: (3'') select() system call can be interrupted with pthread_kill(). But on cygwin system, pthread_kill() doesn''t work well. oops. If we use the code that I sent, we may have problems wih cygwin. BUT: 1) (I hope that) no sane human will run a production server in cygwin 2) This problem would only happen in cygwin when stopping mongrel, so it''s not really one of the biggest problems in the world. Also, besides using the code already sent, we could call accept_nonblock() and then get into a loop calling select in the socket for a limited time and then check a variable to exit. Something like this: serv = TCPServer.new(''127.0.0.1'', 3000) begin sock = serv.accept_nonblock rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR #executes select for 3 seconds before try our exit variable IO.select([serv], nil, nil, 3) return if die retry end This way we just set @acceptor.die = true, join it and wait. How about it? Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru }
On Dec 27, 2007 1:07 AM, Filipe <filipe at icewall.org> wrote: [...]> > Thanks for the links :) > > Well, one important note from ko1 in one of those links: > > (3'') select() system call can be interrupted with pthread_kill(). But > on cygwin system, pthread_kill() doesn''t work well. oops. > > If we use the code that I sent, we may have problems wih cygwin. BUT: > 1) (I hope that) no sane human will run a production server in cygwin > 2) This problem would only happen in cygwin when stopping mongrel, so it''s not > really one of the biggest problems in the world. >Yeah, cygwin is not a good alternative, even that some editors (like E) encourage users to use a cygwin environment to "mimic" linux. I give support for mongrel on "mswin32" platform, not cygwin (hey, I even plan to support mingw when get it working right).> Also, besides using the code already sent, we could call accept_nonblock() > and then get into a loop calling select in the socket for a limited time and then > check a variable to exit. Something like this: > > serv = TCPServer.new(''127.0.0.1'', 3000) > begin > sock = serv.accept_nonblock > rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR > #executes select for 3 seconds before try our exit variable > IO.select([serv], nil, nil, 3) > return if die > retry > end > > This way we just set @acceptor.die = true, join it and wait. How about it? >That could work, but we will still be attached/limited/sticked/busted to Threads. one developer started a thread at ruby-core listing the ''evented'' frameworks available, how bad they behave and listing part of the problems they currently present. Also, describe that something could be done in the Fibers arena to workaround this, thus removing the need for external C code: http://groups.google.com/group/ruby-core-google/browse_thread/thread/fbf8bae96b00d1f5 [ruby-core:14497] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14497 But still, don''t have free time to look deep into this (damn work, I hate it, need to code some usb driver for windows by tonight). For the time being, I suggest we take stable 1.1 and: force required_ruby_version ''<1.9.0'' release a new gems for it (I''ll do the same for the pre-build binary). Volunteers? :-D I''m working on getting mongrel_service fixed (removing win32-service dependency since latest version broke API and affect GemPlugin namespace) I''ll add the same forced ruby_version to it. I don''t ask for volunteers here, but if someone can, it''s really welcome :-D Regards, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Thu, 27 Dec 2007, Luis Lavena wrote:> On Dec 27, 2007 1:07 AM, Filipe <filipe at icewall.org> wrote: > [...] >> >> bla bla bla > > Yeah, cygwin is not a good alternative, even that some editors (like > E) encourage users to use a cygwin environment to "mimic" linux. > > I give support for mongrel on "mswin32" platform, not cygwin (hey, I > even plan to support mingw when get it working right).I installed a cygwin... gonna try to build ruby1.9 + mongrel on it today. But this thing is damn slow... say, vmware player running debian runs ruby1.9''s ./configure a lot faster than cygwin.> >> Also, besides using the code already sent, we could call accept_nonblock() >> and then get into a loop calling select in the socket for a limited time and then >> check a variable to exit. Something like this: >> >> serv = TCPServer.new(''127.0.0.1'', 3000) >> begin >> sock = serv.accept_nonblock >> rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR >> #executes select for 3 seconds before try our exit variable >> IO.select([serv], nil, nil, 3) >> return if die >> retry >> end >> >> This way we just set @acceptor.die = true, join it and wait. How about it? >> > > That could work, but we will still be attached/limited/sticked/busted > to Threads.Yeah.. and it also uses select... just noticed that after I sent. Maybe the best aproach is really drop it all and rewrite this from scratch using events. Now.. which lib to use? The is event machine, zed''s rev, ezmorbius'' packet... lot of options. I think here wyhaines could give us a big hand!> > one developer started a thread at ruby-core listing the ''evented'' > frameworks available, how bad they behave and listing part of the > problems they currently present. > > Also, describe that something could be done in the Fibers arena to > workaround this, thus removing the need for external C code:Yeap I''m following this... hope this discussion goes a long way to help us decide :)> > But still, don''t have free time to look deep into this (damn work, I > hate it, need to code some usb driver for windows by tonight).:( Good luck...> > For the time being, I suggest we take stable 1.1 and: > > force required_ruby_version ''<1.9.0'' > release a new gems for it (I''ll do the same for the pre-build binary). > > Volunteers? :-DHey, evn is our release guy ;)> > I''m working on getting mongrel_service fixed (removing win32-service > dependency since latest version broke API and affect GemPlugin > namespace) > I''ll add the same forced ruby_version to it. > > I don''t ask for volunteers here, but if someone can, it''s really welcome :-DThanks for not asking... Cheers, filipe
On Dec 27, 2007 5:45 AM, Filipe Lautert <filipe at icewall.org> wrote:> Maybe the best aproach is really drop it all and rewrite this from > scratch using events. Now.. which lib to use? The is event machine, > zed''s rev, ezmorbius'' packet... lot of options. > > I think here wyhaines could give us a big hand!We''re in a situation where having a single version that is compatible with 1.8.x and 1.9.x means suboptimal performance on 1.9.x. So.... The choices: 1) Rewrite the network core to make use of a thread pool, and keep Mongrel, natively, as a threaded app based on core ruby facilities. 2) Rewrite the network core in an evented style of some sort. 2a) Use pure Ruby, maybe with something like hemant''s packet.rb. Performance on this is not bad, but it retains the select() limitations. On the other hand, being pure ruby it''ll run anywhere without any problems, including windows machines and machines that lack compilers, and will ease the packaging chores. I don''t know how well packet works on jruby, but it may also ease the chore of maintaining Mongrel on that platform if it works adequately there, too. 2b) Use an event framework with an extension at its core. The main options here are really Tony Aceri''s Rev, which is a brand new release, written specifically for Ruby 1.9, that uses libev under the covers, or EM. EM itself needs work before it''s really 1.9 ready, though, because it''s current design is optimized for best performance with 1.8 thread semantics.... Tony and I have had a couple conversations recently about the possibility of using Rev as the reactor in the pure ruby version of EM, too. The drawbacks to Rev are that is currently doesn''t work on Windows, it is _very_ new, and libev, while based on libevent, is itself pretty new. I think there are a few things that are important for Mongrel. Two things, really. 1) It should run just about everywhere that Ruby does, including Windows machines. 2) It should perform pretty well everywhere that it runs. 3) It needs to remain stable. A lot of people depend on Mongrel, so we need to be conservative about changes, and do a lot of due diligence work before making any radical changes to the core. I don''t think it has to run faster than anything else out there. It doesn''t right now. ServerSide, for example, is a lot faster, but people host their stuff on Mongrel because Mongrel because of all of the other advantages Mongrel confers. To me, the immediate release goal should be to just repackage the current gem with a ruby version requirement on it < 1.9.0. Then, the next immediate goal should be to release a separate gem that simply works with 1.9.0. It''s not a major set of changes. It doesn''t matter that it doesn''t work optimally so long as it does at least work. We can very, very clearly state that it''s a _development_ release, and is not intended for production use. Then, third, we look at 1.9 specific changes/rewrites for performance. IMHO, we should lean towards a thread pool architecture, or a pure ruby event architecture for the base design (both of which should then work nearly unchanged on jruby, which would be good) unless developments procede in a way that lets us guarantee accessiblity of Mongrel on platforms like Windows with an event-extension based design. Kirk Haines
On Dec 27, 2007 1:47 PM, Kirk Haines <wyhaines at gmail.com> wrote:> On Dec 27, 2007 5:45 AM, Filipe Lautert <filipe at icewall.org> wrote: > > Maybe the best aproach is really drop it all and rewrite this from > > scratch using events. Now.. which lib to use? The is event machine, > > zed''s rev, ezmorbius'' packet... lot of options. > > > > I think here wyhaines could give us a big hand! > > We''re in a situation where having a single version that is compatible > with 1.8.x and 1.9.x means suboptimal performance on 1.9.x. > > So....(my comments below)> The choices: > > 1) Rewrite the network core to make use of a thread pool, and keep > Mongrel, natively, as a threaded app based on core ruby facilities.+1> 2) Rewrite the network core in an evented style of some sort. > 2a) Use pure Ruby, maybe with something like hemant''s packet.rb. > Performance on this is not bad, but it retains the select() > limitations. On the other hand, being pure ruby it''ll run anywhere > without any problems, including windows machines and machines that > lack compilers, and will ease the packaging chores. I don''t know how > well packet works on jruby, but it may also ease the chore of > maintaining Mongrel on that platform if it works adequately there, > too.I want to remember you that our ragel parser still requires compilation, as far we ship pre-compiled gems, we will be good on that subject.> 2b) Use an event framework with an extension at its core. The main > options here are really Tony Aceri''s Rev, which is a brand new > release, written specifically for Ruby 1.9, that uses libev under the > covers, or EM. EM itself needs work before it''s really 1.9 ready, > though, because it''s current design is optimized for best performance > with 1.8 thread semantics.... Tony and I have had a couple > conversations recently about the possibility of using Rev as the > reactor in the pure ruby version of EM, too. The drawbacks to Rev are > that is currently doesn''t work on Windows, it is _very_ new, and > libev, while based on libevent, is itself pretty new.Evented models are too radical from what Mongrel is currently now. Jumping on *any* of these frameworks (no matter if its EM or Rev) will require us a lot of effort. by pure-ruby you mean plain ruby code? It seems Rev uses a extension, which require you compile and thus, depending on it will require us (I mean: me) shipping pre-compiled versions for Windows.> I think there are a few things that are important for Mongrel. Two > things, really. > > 1) It should run just about everywhere that Ruby does, including > Windows machines.+1, we have achieved that.> 2) It should perform pretty well everywhere that it runs.It currently does, even with slowest VC6 build on Windows, Mongrel feels snappy (Mongrel, not Rails).> 3) It needs to remain stable. A lot of people depend on Mongrel, so > we need to be conservative about changes, and do a lot of due > diligence work before making any radical changes to the core. >+100 on this, I''m against huge and compulsive changes to the ''core'', and pointed that several times before.> I don''t think it has to run faster than anything else out there. It > doesn''t right now. ServerSide, for example, is a lot faster, but > people host their stuff on Mongrel because Mongrel because of all of > the other advantages Mongrel confers. >> To me, the immediate release goal should be to just repackage the > current gem with a ruby version requirement on it < 1.9.0. >1.1.3?> Then, the next immediate goal should be to release a separate gem that > simply works with 1.9.0. It''s not a major set of changes. > It doesn''t matter that it doesn''t work optimally so long as it does at > least work. We can very, very clearly state that it''s a _development_ > release, and is not intended for production use. >We can put these gems in mongrel.rubyforge.org/releases, to avoid users downloading them by mistake during "gem update". I need to confirm that required_ruby_version (part of rubygems specifications) is working, will do it later today. If it work as we expect, will be no need for the special /release/ and we can use rubyforge instead.> Then, third, we look at 1.9 specific changes/rewrites for performance. > IMHO, we should lean towards a thread pool architecture, or a pure > ruby event architecture for the base design (both of which should then > work nearly unchanged on jruby, which would be good) unless > developments procede in a way that lets us guarantee accessiblity of > Mongrel on platforms like Windows with an event-extension based > design.As commented before, I''m interested in Rev (and libev). I wrote my own evented library for sockets in FB almost 2 years ago, and was a great experience. Looking at C code will be really nice (nice?) after so long (without counting ruby and mongrel C code, will be 5 years). By the way Rev is structured, I don''t see will be major troubles adjusting/correcting it to work on windows, but the lack of extensive test suite (or specs) and the lack of benchmarks to compare with make me think twice before invest time on this. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 27, 2007 10:30 AM, Luis Lavena <luislavena at gmail.com> wrote:> I want to remember you that our ragel parser still requires > compilation, as far we ship pre-compiled gems, we will be good on that > subject.Right. There is a possibility that the pure ruby one might not suck on 1.9.x, but I''m not holding my breath. However, the ragel based extension is a bit different than using an extension based event framework that itself has to work on all of the platforms that we are targetting.> by pure-ruby you mean plain ruby code? It seems Rev uses a extension, > which require you compile and thus, depending on it will require us (I > mean: me) shipping pre-compiled versions for Windows.Packet is pure ruby. That''s what I was referring to. There''s a pure ruby EM, but for our purposes right now, I think packet is faster (though I have not done any benchmarks on the pure ruby stuff; that''s just a hunch). Kirk
On Dec 27, 2007 2:42 PM, Kirk Haines <wyhaines at gmail.com> wrote:> On Dec 27, 2007 10:30 AM, Luis Lavena <luislavena at gmail.com> wrote: > > > I want to remember you that our ragel parser still requires > > compilation, as far we ship pre-compiled gems, we will be good on that > > subject. > > Right. There is a possibility that the pure ruby one might not suck > on 1.9.x, but I''m not holding my breath. However, the ragel based > extension is a bit different than using an extension based event > framework that itself has to work on all of the platforms that we are > targetting.Maybe it suck less, but as I pointed in previous emails on the list, on 1.9 there wasn''t "overhead" on calling C functions or pure-ruby ones.> > by pure-ruby you mean plain ruby code? It seems Rev uses a extension, > > which require you compile and thus, depending on it will require us (I > > mean: me) shipping pre-compiled versions for Windows. > > Packet is pure ruby. That''s what I was referring to. There''s a pure > ruby EM, but for our purposes right now, I think packet is faster > (though I have not done any benchmarks on the pure ruby stuff; that''s > just a hunch).Based on rumors (comments on ruby-core) it seems EM is not designed for 1.9 and do a intense use of rb_thread_schedule and rb_funcall -- maybe I should call it abuse ;-) Damn, I really hate we can do so many things to test and research but not enough time to actually do it! :-P -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
> Based on rumors (comments on ruby-core) it seems EM is not designed > for 1.9 and do a intense use of rb_thread_schedule and rb_funcall -- > maybe I should call it abuse ;-)Regarding 1.9, I mentioned that in my earlier email. It was designed to work optimally with the 1.8 threading model. What this involves is making calls to rb_thread_select at specific points in the event loop so that Ruby has a chance to do its thing. rb_funcall comes into play when events are being triggered. The architecture isn''t really an abuse of rb_funcall. What happens is that there is an event_callback method that the extension calls. The event_callback method is in pure ruby, and it, in turn, dispatches the event callbacks that one wrote in one''s protocol class. If Ruby''s method dispatch were faster, it''d be a non-issue, and would constitute a nice, modular design. Because Ruby''s method dispatch isn''t fast, though, I have an optimization that I am waiting to commit that more than halves the amount of time taken to dispatch events.> Damn, I really hate we can do so many things to test and research but > not enough time to actually do it! :-PYeah. I know. :( A person could _easily_ work full time on this sort of stuff, if there were money in it. Kirk
On Thu, 27 Dec 2007, Kirk Haines wrote:> ... >> Damn, I really hate we can do so many things to test and research but >> not enough time to actually do it! :-P > > Yeah. I know. :( A person could _easily_ work full time on this > sort of stuff, if there were money in it.Yeap, sad. Someone from the team could have vacations to do it ;) Anyway, I really liked the idea of release 1.1.3 for ruby < 1.9.0, release a version that just works on ruby 1.9 and play new core things to a new major release (2.0?) . Also, we have some things that could be released in a 1.2 release, like logging facility. So, by the talks that I see for 1.9 support here in the list, it seems that we are really going to an event based/thread based approach, is it? And the preference is for a pure ruby approach. Got it? Cheers, Filipe
I''m gonna see if CNET can give me some official time for Mongrel work. Dunno if it will happen though. Evan On Dec 27, 2007 1:22 PM, Filipe Lautert <filipe at icewall.org> wrote:> On Thu, 27 Dec 2007, Kirk Haines wrote: > > ... > >> Damn, I really hate we can do so many things to test and research but > >> not enough time to actually do it! :-P > > > > Yeah. I know. :( A person could _easily_ work full time on this > > sort of stuff, if there were money in it. > > Yeap, sad. Someone from the team could have vacations to do it ;) > > Anyway, I really liked the idea of release 1.1.3 for ruby < 1.9.0, > release a version that just works on ruby 1.9 and play new core things to > a new major release (2.0?) . > > Also, we have some things that could be released in a 1.2 release, like > logging facility. > > So, by the talks that I see for 1.9 support here in the list, it seems that > we are really going to an event based/thread based approach, is it? And > the preference is for a pure ruby approach. Got it? > > Cheers, > > Filipe > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
I am in favor of: * Keeping as much of Mongrel core as it is, if possible. * Rewriting only what is needed to target a thread pool (configurable) and/or evented implementation (I believe that adding support for both would be ideal). ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20071227/e1ee52f8/attachment.html
On Thu, 27 Dec 2007 14:30:07 -0300 "Luis Lavena" <luislavena at gmail.com> wrote:> On Dec 27, 2007 1:47 PM, Kirk Haines <wyhaines at gmail.com> wrote: > > On Dec 27, 2007 5:45 AM, Filipe Lautert <filipe at icewall.org> wrote: > > > Maybe the best aproach is really drop it all and rewrite this from > > > scratch using events. Now.. which lib to use? The is event machine, > > > zed''s rev, ezmorbius'' packet... lot of options.No, that''s a bad idea, and again I keep saying and again people keep suggesting it so I''ll say it one more time: Use only what''s available in Ruby from the beginning (select and threads) for the base mongrel IO processing, and then have a mod for other methods. There''s a reason: Other event systems and libs that are not part of ruby will get stomped on by all the different Ruby implementations, and if a new ruby comes out that isn''t retarded you''ll all get bit in the ass trying to use it. That means, use regular ruby with minimal gear for the base mongrel. Not evented libraries. Additionally: Event based systems are not a cure for speed. They are a lame hack for getting around most operating system''s shitty AIO or thread implementations. If you don''t always have your vanilla source tree you''ll get screwed when these systems improve. It happens all the time so learn from past mistakes. And finally: Mongrel is also a library. The problem with event libs is once you use them they are viral and always require everything else to start using the event system. If the only way someone can embed mongrel in their little app is to also include all of EM or Rev and then hook their crap into that event loop then you''ve all failed hard.> > We''re in a situation where having a single version that is compatible > > with 1.8.x and 1.9.x means suboptimal performance on 1.9.x. > > > > So....Sigh, metrics and evidence please. Without those a debate on performance is meaningless.> > The choices: > > > > 1) Rewrite the network core to make use of a thread pool, and keep > > Mongrel, natively, as a threaded app based on core ruby facilities.Now, this is doable, and I did this intially, so I''ll lay out some original design choices I tried and why I didn''t do them: 1) select based reactor to a state machine based processor. Worked great and was fast, but crashed HARD when you put it in a thread since ruby confused using select in a thread with having to deadlocked threads. This is because ruby (used to?) not properly mesh the thread select processing with regular select calls so juggling this was a nightmare. This was actually the absolute fastest thing I built except for this last flaw. 2) Thread pool reading of a single work queue at random with a feeder thread. This was not fast at all. The thread queues were so slow then and buggy that they were next to useless, and they aslo didn''t allocate to the readers at random. Also the contention between the main master read/accept thread and the other threads made this not work so well. 3) Select loop to read the request, then put that on a thread queue. Combined both problems for a spectacular disaster. 4) Create new thread for each request. This is what you have now. So, I''d say try these again, with the select+FSM approach first and then see what you get. The #1 approach worked great as long as you didn''t put the select inside a thread, and it''d basically be a lo-fi event system that everyone can love. A thread queue would be next but you''d probably have a lot of work to do on that.> > I think there are a few things that are important for Mongrel. Two > > things, really. > > > > 1) It should run just about everywhere that Ruby does, including > > Windows machines. > > +1, we have achieved that.Not really, the requirement is that it run embedded inside anything with just a few little calls and a thread. See above for why EM, Rev, or Packrat don''t satisfy that.> > To me, the immediate release goal should be to just repackage the > > current gem with a ruby version requirement on it < 1.9.0. > > > > 1.1.3?That''s what I''d shoot for in the next release, also, what happened to giving people the ablity to put in their own "work handler" so that this problem becomes somebody else''s problem? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Thu, 27 Dec 2007, Wayne E. Seguin wrote:> I am in favor of: > > * Keeping as much of Mongrel core as it is, if possible. > * Rewriting only what is needed to target a thread pool (configurable) > and/or evented implementation (I believe that adding support for both would > be ideal).WHOW, now here is a new thing for me. wyhaines and zed agreeing about something! Then let us play with threads! Btw, with commits from today to trunk, just one test is not running on ruby 1.9 . But I''m already discuting this at ruby-core list (I wrote a resume at my blog anyway), because this is a Net::HTTP problem, and not a mongrel one. So, by now trunk builds in 1.8 and 1.9 and passes all tests (except this one) for both! Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E http://filipe.icewall.org/ }
On Dec 27, 2007 11:57 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> > > > We''re in a situation where having a single version that is compatible > > > with 1.8.x and 1.9.x means suboptimal performance on 1.9.x. > > > > > > So.... > > Sigh, metrics and evidence please. Without those a debate on > performance is meaningless. >I can confirm that thread spawning and context switching in 1.9 is more expensive than 1.8, done some tests but didn''t collect the data for posterity (or for later big discussion and metrics comparison with you Zed) :-D Also, done some testing regarding C function calling and pure-ruby function calling overhead, being 1.9 slower than 1.8 in pure-ruby calling.> > > The choices: > > > > > > 1) Rewrite the network core to make use of a thread pool, and keep > > > Mongrel, natively, as a threaded app based on core ruby facilities. > > Now, this is doable, and I did this intially, so I''ll lay out some > original design choices I tried and why I didn''t do them: > > 1) select based reactor to a state machine based processor. Worked > great and was fast, but crashed HARD when you put it in a thread since > ruby confused using select in a thread with having to deadlocked > threads. This is because ruby (used to?) not properly mesh the thread > select processing with regular select calls so juggling this was a > nightmare. This was actually the absolute fastest thing I built > except for this last flaw. >Did you keep that original code somewhere? A few things improved regarding this topic, or at least they seem in 1.9> 2) Thread pool reading of a single work queue at random with a feeder > thread. This was not fast at all. The thread queues were so slow > then and buggy that they were next to useless, and they aslo didn''t > allocate to the readers at random. Also the contention between the > main master read/accept thread and the other threads made this not work > so well. >Can''t comment on this, my brain is still trying to understand what you wrote.> 3) Select loop to read the request, then put that on a thread queue. > Combined both problems for a spectacular disaster. > > 4) Create new thread for each request. This is what you have now. >This is resource expensive, I''ll collect some sample data this weekend and show to you the problem that is present in 1.9 regarding this. I''ve followed that path before, but on FreeBASIC, and faced the same results, FB threads where native (linux and windows) but wasn''t scalable, too many threads bring the OS down, linux or windows. Didn''t test it on Solaris, which have a better threading functionality to compare with.> > > I think there are a few things that are important for Mongrel. Two > > > things, really. > > > > > > 1) It should run just about everywhere that Ruby does, including > > > Windows machines. > > > > +1, we have achieved that. > > Not really, the requirement is that it run embedded inside anything > with just a few little calls and a thread. See above for why EM, Rev, > or Packrat don''t satisfy that. >I was talking about *current* mongrel, not the hypothetical evented one.> > > To me, the immediate release goal should be to just repackage the > > > current gem with a ruby version requirement on it < 1.9.0. > > > > > > > 1.1.3? > > That''s what I''d shoot for in the next release, also, what happened to > giving people the ablity to put in their own "work handler" so that > this problem becomes somebody else''s problem?Mmm, don''t follow you on that. You mean allow pluggable replacement for HttpServer? -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Dec 28, 2007 6:59 AM, Luis Lavena <luislavena at gmail.com> wrote:> > That''s what I''d shoot for in the next release, also, what happened to > > giving people the ablity to put in their own "work handler" so that > > this problem becomes somebody else''s problem? > > Mmm, don''t follow you on that. You mean allow pluggable replacement > for HttpServer?I think Zed is referring to the suggestion that the portion of the guts that deals with network IO interactions, and the idea that we make that more modular so that it is easy to plug different architectures into it. Kirk Haines
Zed, Can you elaborate on the thread pool problems you had? Do you think any of these will be mitigated by YARV threads (better scheduling etc). Evan On Dec 28, 2007 10:02 AM, Kirk Haines <wyhaines at gmail.com> wrote:> On Dec 28, 2007 6:59 AM, Luis Lavena <luislavena at gmail.com> wrote: > > > > That''s what I''d shoot for in the next release, also, what happened to > > > giving people the ablity to put in their own "work handler" so that > > > this problem becomes somebody else''s problem? > > > > Mmm, don''t follow you on that. You mean allow pluggable replacement > > for HttpServer? > > I think Zed is referring to the suggestion that the portion of the > guts that deals with network IO interactions, and the idea that we > make that more modular so that it is easy to plug different > architectures into it. > > > Kirk Haines > > _______________________________________________ > Mongrel-development mailing list > Mongrel-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-development >-- Evan Weaver Cloudburst, LLC
On Fri, 28 Dec 2007 19:23:27 -0500 "Evan Weaver" <evan at cloudbur.st> wrote> Zed, > > Can you elaborate on the thread pool problems you had? Do you think > any of these will be mitigated by YARV threads (better scheduling > etc).They might be gone in YARV since the threading is more real and (supposedly) higher performance. My problem was mostly that putting the requests through a thread queue was a lot slower (1/2 speed iirc) than just making new threads. Without a queue though it''s really difficult to do a pool of processors model. I tried using the plain synchronized primitives but that turned out to be the same problem for speed, especially when combined with rails. Finally, in order for a set of queue listeners to work properly the selection of the next processor/listener to receive a queue entry has to be fairly random. However I found that it wasn''t that random and usually it was more first-come-first served. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
Filipe
2008-Jan-15 13:39 UTC
[Mongrel-development] trunk performance running on 1.8 and 1.
Hi guys, I did some benchmarks of trunk running on ruby 1.8 and 1.9 in the beginning of the year, and I''ve posted it at my blog (the one in the signature). A cool thing to note: even without tunnings to mongrel running in ruby 1.9, it has the same performance that with ruby 1.8. There is the know problem of CTRL+C doesn''t exit gracefully, but anyway I think mongrel is ready to be tested in the developer release of ruby. Also, after finish this "1.9 port" (at least it builds and run now), I gonna take some vacation from mongrel development for 2 or 3 months because I *need* to finish a big project here. I''ll still @irc and reading the mailling list, but will stop my commits for a while. Cheers, filipe { @ icewall.org GPG 1024D/A6BA423E http://filipe.icewall.org/ }
Wayne E. Seguin
2008-Jan-15 20:45 UTC
[Mongrel-development] trunk performance running on 1.8 and 1.
Filipe, Awesome! Thanks for hammering this out for us. Good luck with you''re big project. tty on IRC :) ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-development/attachments/20080115/29030493/attachment.html