Getting EADDRINUSE with high load

[Shazwazza]

I'm not a nodejs dev so I'm not entirely sure what this means but from everything I've read it seems like this shouldn't occur.

A similar issue was reported quite some time ago here #90.

I'm using the latest 1.7.2 and using this simple config:

config:
  phases:
    - duration: 30
      arrivalRate: 200
      rampTo: 600
scenarios:
  - name: "Test"
    flow:
      - get:
          url: "/"

I haven't tested if I get the same result in 1.6.x but seems quite similar to the previous report. If I run netstat after the run there are thousands of items in TIME_WAIT for mynews (not sure why it's mynews?) Eventually those go away but they are created from artillery.

I can't push my site it's peek without this result. I'm assuming this shouldn't occur but let me know otherwise and any tips for how I can push the RPS high enough for this page to start showing some lag.

All virtual users finished
Summary report @ 23:18:11(-0700) 2021-05-20
  Scenarios launched:  12131
  Scenarios completed: 9600
  Requests completed:  9600
  Mean response/sec: 290.49
  Response time (msec):
    min: 3
    max: 46
    median: 7
    p95: 11
    p99: 15
  Scenario counts:
    FrontEnd: 12131 (100%)
  Codes:
    200: 9600
  Errors:
    EADDRINUSE: 2531

[hassy]

Hi @Shazwazza 👋 If you want to push higher RPS, I'd suggest reducing the number of arrivals and using a loop instead to push more requests over the same TCP connection (docs on loops)

What your test is doing at the moment is creating hundreds of new TCP connections per second to send just one GET request on each - that's a lot of overhead (and most of that work will be done by the OS - not the app).

Seeing lots of connections in TIME_WAIT is normal - a TCP connection will be kept around for a while by the OS even after the application (Artillery in this case) has closed it. That's why you're seeing lots of them in the output from netstat - they should disappear after a while.

[hassy]

EADDRINUSE means the application is trying to use a port which is already in use - you'd usually see this if you're trying to start a server on port N when there's something else listening on that port already. Not sure why you'd see that error on the client (i.e. in Artillery) - what OS / version of Node.js is this?

[Shazwazza]

@hassy many thanks! I knew I was missing something :) I had artillery working quite a long time ago with pushing huge throughput but couldn't remember how - loops of course 🤦‍♂️

My nodejs version is v12.19.0 and I'm on Windows 10 Pro 20H2

With loops I know longer get the EADDRINUSE. Feel free to close unless you think that it's an issue that shouldn't really occur. Cheers!

[sateffen]

The issue is windows itself.

The OS has a fixed pool of total TCP connections it can handle. On windows it's about 4.000 concurrent TCP connections. After a TCP connections gets "closed" by the application, windows keeps it in TIME_WAIT for about 120 seconds, which results in exhausting the available ports for new TCP connections.

As you start 200 new connections every 30 seconds, the system tries to open up 6000 TCP connections, which windows can't handle. There is no way artillery can circumvent this, other than gracefully embrace such errors or limitations and tell the user about it I guess.

You can follow this documentation to fine-tune windows for load-testing.

[yaniv-aplica]

This just saved me soooooo much frustration! moved the test on a mac the all works fine.