thanks for the constructive feedback daniel. On Wednesday, April 3, 2013 12:39:23 AM UTC+1, dshaw wrote: > > I'm just going to leave this here: > https://vimeo.com/56402326 > > Daniel Shaw > @dshaw > > > On Tue, Apr 2, 2013 at 1:33 PM, billywhizz <[email protected]<javascript:>> > wrote: > > i tend to agree. i would like core to be just a very small wrapper > around > > libuv and everything else to be in user land. but it's too late for > those > > kind of arguments at this stage. having said that, it is quite easy to > build > > your own stripped down node.js with almost all of the js removed. i can > post > > an example of this up on github if anyone is interested. on my system i > can > > knock 2-3MB off the startup image size and have most of what i need with > > only 5-6 MB RSS in use. > > > > > > On Tuesday, April 2, 2013 9:27:46 PM UTC+1, 3rdEden wrote: > >> > >> I just want to be the first who says this: > >> > >> YEAH! HTTP/TCP doesn't belong in core! Move it all to user land! > >> > >> But in all seriousness, impressive stats, it just shows how much more > >> performance there is to gain in Node.js. > >> > >> On Tuesday, April 2, 2013 at 1:57 PM, billywhizz wrote: > >> > >> just wanted to get some feedback on some experiments i have been doing > in > >> getting maximum http performance in node.js. the code is here: > >> > >> https://github.com/billywhizz/minhttp > >> > >> this is a c++ addon that does the absolute minimum http processing and > >> leaves all decisions to the end user about how much support for http > they > >> want to provide. it uses ryah's http_parser to take care of http > parsing and > >> does some hacky stuff with buffers to ensure no new objects are created > >> between requests. if you run the http-min example you can hammer it > with > >> apachebench and if you run with --trace-gc you will see that there are > NO > >> pauses for garbage collection which makes a huge performance > difference. i > >> played around with a lot of different techniques for achieving max > >> performance and settled on the one it is currently using which is > basically > >> as follows: > >> > >> - client provides an input buffer and an output buffer to the library > when > >> it is initialised. no other buffers need to be created when receiving > >> requests or writing responses. for writes, the memcpy is taken care of > in > >> c++ land. for reads this means that once the onResponse callback has > >> finished, the input buffer can be overwritten so it is up to the user > to > >> save the request state according to their needs. > >> - callbacks must be explicitly set using a setCallbacks method which > binds > >> the library to the relevant callbacks at that point. this means we > don't > >> check again if the callbacks exist which saves quite a bit of cpu time > >> - parsing the request requires some nasty binary parsing but this pays > off > >> big time performance-wise compared to creating lots of js objects which > have > >> to be GC'd > >> > >> on my hardware i can get 67k responses a second for the absolute > minimal > >> case (just return a 200 OK keepalive request for every response). this > >> compares to a minimal server using node.js http library giving 12k rps > which > >> is quite a boost. i have also tested it as a very basic static file > server > >> and can get the same performance as optimised nginx on my hardware. > memory > >> overhead is only 2-3 MB more than nginx too due to the fact that no > objects > >> are being created on the fly. > >> > >> not sure if this approach is viable in the real world but would be > >> interested in any feedback/ideas/gotchas that people might come up > with. i > >> would like to turn it into a low level http/tcp binding that could be > useful > >> for people who need really low level access to the protocols or might > be > >> running on a device with limited memory/cpu. > >> > >> bear in mind this is very much a first pass at this so expect segfaults > >> and all sorts of bad things to happen if anything unexpected happens. > will > >> be looking at making it more robust next. > >> > >> -- > >> -- > >> Job Board: http://jobs.nodejs.org/ > >> Posting guidelines: > >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > >> You received this message because you are subscribed to the Google > >> Groups "nodejs" group. > >> To post to this group, send email to [email protected] > >> > >> To unsubscribe from this group, send email to > >> [email protected] > >> > >> For more options, visit this group at > >> http://groups.google.com/group/nodejs?hl=en?hl=en > >> > >> --- > >> You received this message because you are subscribed to the Google > Groups > >> "nodejs" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> > >> For more options, visit https://groups.google.com/groups/opt_out. > >> > >> > >> > >> > > -- > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "nodejs" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > >
-- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
