Hummm, maybe try redoing this using tomcat / rails / PHP.... no wait, that
won't be any faster. How about a shell script and netcat / mod_perl / cobol
on cogs.

Ah no, that won't work either. New idea - grow smarter and stop wasting
time. $$$ says gearman is the bottleneck ab is giving you stats on anyway
(I don't care if that is right or not, my gut tells me this pure stupidity).

<end troll>
On Apr 12, 2012 6:59 PM, "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<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
>>> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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
>

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

Reply via email to