0.135.1 slower webhook response time

Hello,

after upgrading to newest version (from 0.134.0) the webhook response time got slower.
Although if the response mode is set to “On received” the response time doesn’t change (varies from 150 to 250 ms)
Thus “Last Node” - “First Entry JSON” combination behaves slower with the new version:

  • v 0.134.0 - varies from 1600 to 2500 ms
  • v 0.135.1 - varies from 4500 to 5600 ms

Is this a feature or a bug? :confused:

P.S.: EXECUTIONS_PROCESS = own
P.S.S.: Response times where tested with this workflow

{
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "0cb9d6f9-8c91-43ef-b8ba-75e20441a0ab",
        "responseMode": "lastNode",
        "options": {}
      },
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [
        400,
        300
      ],
      "webhookId": "0cb9d6f9-8c91-43ef-b8ba-75e20441a0ab"
    },
    {
      "parameters": {
        "functionCode": "return {\n result: \"TEST\"\n}"
      },
      "name": "FunctionItem",
      "type": "n8n-nodes-base.functionItem",
      "typeVersion": 1,
      "position": [
        600,
        300
      ]
    }
  ],
  "connections": {
    "Webhook": {
      "main": [
        [
          {
            "node": "FunctionItem",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Very strange. Sorry to hear. What database are you using? Is it running on the same server?

Because the only thing that I can imagine right now which could cause that, is that we now read the credentials always from the database. But that should be normally super fast. Only if the database connection is very slow should that have any meaningful impact.

Hi @jan,

I’m using native database (SQLITE).

Very strange. Let me test if I can reproduce that.

Yes, can confirm that. When using the “main” mode both behave the same (which I would suggest if speed matters). Only when using the “own” mode does it get suddenly very slow. We will have a look at what is going on there.

1 Like

Sadly the main mode has other downsides. Using it random crashes occur (log output below). I’ve tried to find a pattern why, but wasn’t able to identify the root cause.

Anyway crash issue is not related to this one :sweat_smile:

P.S.: I think the crashes are more related to node.js version that n8n uses. Additionally I’m using /healthz every 30s to check the application response

2021-08-11T18:05:35.167+03:00	events.js:292

2021-08-11T18:05:35.167+03:00	throw er; // Unhandled 'error' event

2021-08-11T18:05:35.167+03:00	^

2021-08-11T18:05:35.167+03:00	Error: read ECONNRESET

2021-08-11T18:05:35.167+03:00	at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)

2021-08-11T18:05:35.167+03:00	Emitted 'error' event on TLSSocket instance at:

2021-08-11T18:05:35.167+03:00	at emitErrorNT (internal/streams/destroy.js:106:8)

2021-08-11T18:05:35.167+03:00	at emitErrorCloseNT (internal/streams/destroy.js:74:3)

2021-08-11T18:05:35.167+03:00	at processTicksAndRejections (internal/process/task_queues.js:80:21) {

2021-08-11T18:05:35.167+03:00	errno: -104,

2021-08-11T18:05:35.167+03:00	code: 'ECONNRESET',

2021-08-11T18:05:35.167+03:00	syscall: 'read'

2021-08-11T18:05:35.167+03:00	}

The issue got fixed by @krynble and just released with [email protected].

Regarding the crash with main mode. Very strange Yes this error message is sadly really not very helpful. You can maybe think about activating logging to narrow down the issue some more.

1 Like

The log level was debug and I didn’t catch anything that could cause that.

I can confirm that now the response time is the same as in 0.134.0!

@krynble :sparkling_heart::pray:

2 Likes