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]> 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] > 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] 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.
