NodeJS refuses connections

[pi]

Hi all,
I was checking the NodeJS performance compared to Apache 2 in serving
same files, using the following script: http://pastebin.com/3hq1hKhq

The results (http://pastebin.com/R5RdeZYC) give a winning Apache, who
was born to do this, but the most significant thing is that under
"heavy" load NodeJS refuses connections! I think I made something
wrong.

All my test with latest NodeJS (0.1.32) on Ubuntu 9.04, tested with
the following command:ab -n 100000 -c 1000 http://127.0.0.1:8080/var/www/index.html

How can I do to ensure that all requests are resolved properly?

Thnak you,
Ivano

[Ryan Dahl]

On Tue, Mar 16, 2010 at 10:13 AM, pi <ivano...@gmail.com> wrote:
> Hi all,
> I was checking the NodeJS performance compared to Apache 2 in serving
> same files, using the following script: http://pastebin.com/3hq1hKhq
>
> The results (http://pastebin.com/R5RdeZYC) give a winning Apache, who
> was born to do this, but the most significant thing is that under
> "heavy" load NodeJS refuses connections! I think I made something
> wrong.

You're loading the file for each request, which Apache certainly isn't
doing. Not that I expect Node to be faster than Apache, but it's a bit
unfair example.

> All my test with latest NodeJS (0.1.32) on Ubuntu 9.04, tested with
> the following command:ab -n 100000 -c 1000 http://127.0.0.1:8080/var/www/index.html
>
>  How can I do to ensure that all requests are resolved properly?

It's difficult to say what's happening. One obvious thing comes to
mind: you should check your ulimit -n to see that Node can have enough
file descriptors open. You also ought to check that it's actually Node
refusing connections and not just ab running out of open ports. (Can
you curl the server from a different host?)

[pi]

> You're loading the file for each request, which Apache certainly isn't
> doing. Not that I expect Node to be faster than Apache, but it's a bit
> unfair example.

I think Apache does almost the same thing,since you can see any
changes in your browser as soon as your file is saved.
However, I test Node with a LRU Cache on contents (without
expiration). This is my pseudo-optimized script: http://pastebin.com/3b7ara5Q

Node results are still far from Apache: 1627.07 rps without Cache,
2139.50 rps with Cache, 3425.83 rps with Apache2, 5896.23 rps with
NGINX (same ab -n 100000 -c 1000 http://127.0.0.1:$PORT/index.html
command). I run my benchs on a single core machine.
Do you have any other ideas to boost performance?

> It's difficult to say what's happening. One obvious thing comes to
> mind: you should check your ulimit -n to see that Node can have enough
> file descriptors open. You also ought to check that it's actually Node
> refusing connections and not just ab running out of open ports. (Can
> you curl the server from a different host?)

You are right, I was stuck on defaults settings (1024). Previous
results are obtain with these:
# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 999999
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Thank you very much,
Ivano

[pi]

Hi all,

just to point out other benchmarks results I got, while NodeJS doesn't
perform well against legacy http servers like Apache or Nginx, it is
really faster than Jaxer (using jaxer-service on Apache running 10
workers): 1204.82 rps vs 53.71 rps.

Great!

bye,
Ivano

[Marak Squires]

Thanks Dr. Nick!

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Isaac Schlueter]

On Wed, Mar 17, 2010 at 07:45, pi <ivano...@gmail.com> wrote:
>> You're loading the file for each request, which Apache certainly isn't
>> doing. Not that I expect Node to be faster than Apache, but it's a bit
>> unfair example.
>
> I think Apache does almost the same thing,since you can see any
> changes in your browser as soon as your file is saved.
> However, I test Node with a LRU Cache on contents (without
> expiration). This is my pseudo-optimized script: http://pastebin.com/3b7ara5Q

Apache stats the file to see if it's changed since last time it was
sent, and sends it from memory if possible, whereas you've got node
doing an open()/read()/close() on every request.

So, yeah, it's a bit of an unfair example. Do the same thing in node,
and it's a bit fairer test.

Ryan: you should expect node to be faster. It is, and it has been for
many versions now. At least, it is on my machine, and that's an
Apache instance with hardly any modules enabled.

http://gist.github.com/335623

Also, you should be using nginx to serve static files, and have it
proxy to node for programmy bits. nginx is faster than lightening on
crack.

--i

[Isaac Schlueter]

Oh, yeah, another thing.

> I think Apache does almost the same thing,since you can see any
> changes in your browser as soon as your file is saved.

Never ever ever ever use a browser to test your http server. Browsers
are for testing html and css and browser-JS. Just because Apache
shows changes "right away" doesn't mean it isn't caching the data. It
just means that modifying the file invalidates the cache.

Use curl for testing http. Use browsers for testing html.

--i

[Akzhan Abdulin]

I suppose that these tests handle another aspect - static content handling. Of course,nginx faster (and it's good choice as http proxy).

But try to test handling of dynamic content.

2010/3/17 Marak Squires <marak....@gmail.com>

[Dean Landolt]

Or if you'd rather something a bit more pleasant than curl download the RESTClient firefox extension.

 

--i

[pi]

Ok, thank you very much for your snippet code. I will try it tomorrow.

>
> Never ever ever ever use a browser to test your http server.  Browsers
> are for testing html and css and browser-JS.  Just because Apache
> shows changes "right away" doesn't mean it isn't caching the data.  It
> just means that modifying the file invalidates the cache.
>
> Use curl for testing http.  Use browsers for testing html.
>
> --i

I don't use browser to test my http server, i tried to explain the
behaviour. In my second test used a LRU cache to store content from
file. So, i read the file in the first round only, the rest come from
cache.

Anyway, thanks again for your support.
Ivano

[Rasmus Andersson]

You should probably compare a node web service to other similar
platforms. For instance a python wsgi app. Nginx and Apache are much
faster than a node app, but come with the cost of very expensive
development.

1000 rps sounds way too low, however.

>
> Great!
>
> bye,
> Ivano

>
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>

--
Rasmus Andersson

[pi]

I've just made some tests with your code. It's really faster than
mine, even with logs (i don't use fs.filewritestream, but i think it
could boost perfomance even more).
Now NodeJS performs better than Apache when concurrent connections is
over 150 (on my virtual machine with default Ubuntu settings).

I also known that the results variance for each 8 cycle per test is
much smaller than with Apache, this seems to me very positive because
loads is more predictable, enabling better infrastructure planning.

Thank you very much,
Ivano

On 17 Mar, 20:27, Isaac Schlueter <i...@izs.me> wrote: