Hmm.. This may be a valid criticism.
However. My gut tells me otherwise. I made the code set for tests incredibly small. And all of the nodeJS/java/groovy are using the same queries in ab testing. (But, this being said, my gut is often wrong though. Maybe there is some flag or something I'm missing in nodeJS.) If I were a nodeJS enthusiast, I would probably get one thing from this email, and that is that the mongo db to javascript mechanisms need to be profiled. As for grails, I probably shouldn't have used groovy for things that need to run fast. But I'm not interested in figuring this out at the moment. Anyhow, your project is really interesting, good luck with it. -tim On Thursday, April 12, 2012 6:43:39 PM UTC-4, Marak Squires wrote: > > 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
