is this a variation of a troll ? On Apr 13, 12:58 am, timp <[email protected]> wrote: > 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
