Perhaps, you should take the time to decide on a single implementation and actually try to figure out what's going on.
I don't really think any of the benchmarks you've posted are indicative of performance for the specific software suite they are benchmarking. On Thu, Apr 12, 2012 at 3:32 PM, timp <[email protected]> wrote: > Hey there, I bring a few updates. > Which may be more an insight into compulsive programmer behavior than > anything else :-) However: > > So yesterday I thought, well, let's see if I just use nodeJS as the front > end, and use java as the backend. > > So what I did, was use "gear man" to create a work queue, which I wrote > into via nodeJS and then had a worker process consuming those tasks and > writing back results. > > (if you think to yourself, well this just sounds stupid, I sort of agree.) > > Anyhow, when I shifted the work to the java, I was able to get the > throughput up to 160 rps .. For "full" login. This means a full > journal/shop/etc... > Which is about 1.5 * more data than I was doing for the 120 rps in nodeJS. > (because I had clipped, and gotten rid of partial datasets) > > So yesterday, I thought to myself. OK. This will be fine. > > --- > > But then today, I thought to myself, "this is just stupid. Using a worker > queue should be SLOWER than using a epoll/kqueue whatnot. > I just don't get why grails would be so much slower than nodeJS in front > of a work queue in front of java." > > So, I thought to myself, let's see if I can get rid of grails. > > At first I was going to use, yet another framework, one called "play" but > after reading their forums, filled with complaints, I thought, ahhh, why am > I even using a framework? > > > And in the last few hours I made a JSP, Web project in eclipse, got it > deployed to Tomcat, and > > WALAH!!!! > > Requests per second: 351.33 [#/sec] (mean) > Full data. > > 10 times faster than grails. (wtf is grails doing?) > 4 times faster than nodeJS. > > > I'm not sure what this means. > I guess it means, if anyone is reading this, having similar performance > issues with basically a REST/JSON service. > Maybe it would be better to skip *all* of the frameworks. > > > Anyway. > > I would still rather have LVMM pages. > > It was fun doing the async + callbacks. Although I will not miss having > no compile time checking. > > Regards, > > -tim > > > On Wednesday, April 11, 2012 8:36:28 AM UTC-4, christkv wrote: >> >> if perf is dropping over time I suspect a possible memory leak causing >> the gc to have to go through longer and longer of uncollectable items. >> >> it might be worth just writing a simple test app dropping mongoskin >> and hitting the driver directly. >> >> On Apr 11, 12:12 am, timp <[email protected]> wrote: >> > Oh well, thanks for your responses so far. >> > >> > If anyone has any real world experiences with scaling and using nodeJS, >> I >> > would be interested in how you set up things computationally. >> > >> > Did you actually have the nodeJS perform work? Or just fetch results? >> > >> > If just fetch results, what did you use on your back end? >> > >> > Especially, did you even use a framework? >> > >> > For instance I can see having maybe 50 workers in java/c#/c++ sitting >> on >> > queues, waiting for requests and feeding them back results. >> > >> > But, I'm interested in what someone says who has actually done it. >> > >> > -tim >> > >> > >> > >> > >> > >> > >> > >> > On Tuesday, April 10, 2012 5:57:01 PM UTC-4, timp wrote: >> > >> > > (I think) I just tried the native bson with the pages >> > >> > > or at least I did this: >> > >> > > pm install mongodb --mongodb:native >> > > seemed to compile things >> > >> > > the mongoskin says it will use it if it is there >> > >> > > tests are coming out about the same. +/- 5 fps >> > >> > > On Tuesday, April 10, 2012 5:46:38 PM UTC-4, Jann Horn wrote: >> > >> > >> Am Dienstag, den 10.04.2012, 10:15 -0700 schrieb timp: >> > >> > But at the same time, I am truly annoyed at how slow these web >> > >> > servers/frameworks are. >> > >> > >> Me too. :D >> > >> > >> I have a small node.js proxy running here, and even when it's just >> > >> piping through a youtube video (using the normal Stream pipe method) >> > >> between the browser and youtube, nodes CPU usage goes way over 10%. >> It >> > >> takes half of what flash uses. >> > >> > >> Well, and if you look closer, you can see that e.g. 15% of the time >> are >> > >> spend with write completion callbacks which are probably nearly >> never >> > >> used. Still, each completed write means that there's a call from C++ >> > >> land into JS land, a bunch of JS code and a call from JS to C++ >> (resume >> > >> input). >> > >> > On Tuesday, April 10, 2012 5:57:01 PM UTC-4, timp wrote: >> > >> > > (I think) I just tried the native bson with the pages >> > >> > > or at least I did this: >> > >> > > pm install mongodb --mongodb:native >> > > seemed to compile things >> > >> > > the mongoskin says it will use it if it is there >> > >> > > tests are coming out about the same. +/- 5 fps >> > >> > > On Tuesday, April 10, 2012 5:46:38 PM UTC-4, Jann Horn wrote: >> > >> > >> Am Dienstag, den 10.04.2012, 10:15 -0700 schrieb timp: >> > >> > But at the same time, I am truly annoyed at how slow these web >> > >> > servers/frameworks are. >> > >> > >> Me too. :D >> > >> > >> I have a small node.js proxy running here, and even when it's just >> > >> piping through a youtube video (using the normal Stream pipe method) >> > >> between the browser and youtube, nodes CPU usage goes way over 10%. >> It >> > >> takes half of what flash uses. >> > >> > >> Well, and if you look closer, you can see that e.g. 15% of the time >> are >> > >> spend with write completion callbacks which are probably nearly >> never >> > >> used. Still, each completed write means that there's a call from C++ >> > >> land into JS land, a bunch of JS code and a call from JS to C++ >> (resume >> > >> input). >> > >> > On Tuesday, April 10, 2012 5:57:01 PM UTC-4, timp wrote: >> > >> > > (I think) I just tried the native bson with the pages >> > >> > > or at least I did this: >> > >> > > pm install mongodb --mongodb:native >> > > seemed to compile things >> > >> > > the mongoskin says it will use it if it is there >> > >> > > tests are coming out about the same. +/- 5 fps >> > >> > > On Tuesday, April 10, 2012 5:46:38 PM UTC-4, Jann Horn wrote: >> > >> > >> Am Dienstag, den 10.04.2012, 10:15 -0700 schrieb timp: >> > >> > But at the same time, I am truly annoyed at how slow these web >> > >> > servers/frameworks are. >> > >> > >> Me too. :D >> > >> > >> I have a small node.js proxy running here, and even when it's just >> > >> piping through a youtube video (using the normal Stream pipe method) >> > >> between the browser and youtube, nodes CPU usage goes way over 10%. >> It >> > >> takes half of what flash uses. >> > >> > >> Well, and if you look closer, you can see that e.g. 15% of the time >> are >> > >> spend with write completion callbacks which are probably nearly >> never >> > >> used. Still, each completed write means that there's a call from C++ >> > >> land into JS land, a bunch of JS code and a call from JS to C++ >> (resume >> > >> input). > > -- > 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 > -- -- Marak Squires Co-founder and Chief Evangelist Nodejitsu, Inc. [email protected] -- 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
