[Mongrel-development] Some silly benchs (was: 1.9)

[Evan Weaver]

> events solve this situation but I haven't looked at any evented lib

Got cut off. I haven't looked at any evented lib in detail.

On Dec 14, 2007 7:43 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Yeah I am not a fan of a regex parser.
>
> What exactly is the deal with events on 1.9? How many connections
> should we realistically expect? Would it be just as good to use
> select()?
>
> My understanding is that Fibers don't cooperatively multitask the way
> green threads do, so I don't think Fibers will offer a way forward
> without horrible hacks. On the other hand, I'm not totally clear how
> events solve this situation but I haven't looked at any evented lib
>
> Is there a way we could re-use a small process pool, and queue extra
> requests in a simple buffer? How many contexts do you need to get
> decent CPU saturation in most situations? Do they usually wait on IO
> 20% of the time, or 60%, or... I realize I am asking for benchmarks
> without any context.
>
> My understand is that WSGI is excellent (Python). How do they handle
> these issues? Python's threads are just like YARV's.
>
> Evan
>
>
> On Dec 14, 2007 7:41 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > On Fri, 14 Dec 2007 19:05:28 -0300
> > "Luis Lavena" <luislavena at gmail.com> wrote:
> >
> > > I'll try to rip the ServerSide::HTTP::Parsing module and drop the same
> > > tests mongrel does to see how it perform (and how valid it is).
> > >
> > > Anyway, the pastie was to show the overhead of calling C functions in
> > > 1.9 compared to the same naive one in pure-ruby.
> > >
> > > Hopefully I wouldn't need to adapt lot of code from ServerSide to make
> > > the tests pass on 1.9.
> >
> > I wouldn't bother.  A cornerstone of Mongrel's design is that by using
> > a parser generated by a mathematically sound (hopefully) parser Mongrel
> > is able to reject about 80% of security hacks simply becuase they
> > usually violate the RFC grammar.
> >
> > This is in essence creating a white list for HTTP requests and
> > rejecting anything else, with very exact reasons based on grammar
> > violations.
> >
> > What Serverside (and every other web server) does is creates a black
> > list for HTTP requests and allowing nearly all of them through.  It
> > gets its speed from basically not being thorough, and it only needs to
> > do this in Ruby.  As the mongrel parser shows you can still use a
> > generator and get a fast as hell http parser.
> >
> > So, running off to a web server that's implemented half assed with the
> > goal of bringing said half-assedness to mongrel in order to improve
> > speed would remove nearly all the other advantages.  That's simply bad
> > engineering all around.
> >
> > It would be better to instead check a Ruby version of the .rl parser
> > against 1.9 and then see what can be done to speed it up without losing
> > it's valuable exactness.
> >
> > --
> > Zed A. Shaw
> > - Hate: http://savingtheinternetwithhate.com/
> > - Good: http://www.zedshaw.com/
> > - Evil: http://yearofevil.com/
> >
> > _______________________________________________
> > Mongrel-development mailing list
> > Mongrel-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-development
> >
>
>
>
> --
> Evan Weaver
> Cloudburst, LLC
>



-- 
Evan Weaver
Cloudburst, LLC