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 <timprepsc...@gmail.com> 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
