I appreciate the colorful responses.

However, I think, the numbers do speak for themselves.

If you are creating basically a mongo JSON REST web service.  And are 
having rps problems with your current framework, using dynamic languages.

It may be worth your while, to remove all the frameworks, and do a jsp war 
deployed in tomcat with no "extras" tagging along.


My web service is a simple mongo retrieval json serialization with a few 
modifications along the way.

Groovy + rails :  (all code in groovy, mongo through gmongo) 15 rps 
nodeJS: 80 rps
nodeJS front end, java back end via a message queue: 160 rps
jsp war, tomcat, no message queue backend (simple):  330


I'm not a troll.
I merely want to spend as little money on the web service as possible.

-tim

p.s. Good luck.


On Saturday, April 14, 2012 12:55:22 AM UTC-4, shawn wilson wrote:
>
> 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