This topic was automatically generated from Slack. You can find the original thread here.
Related to this thread, but I don’t want to hijack it. Slack
Is there a way to optimize initial response? I am seeing the response time as high as 7 seconds to deliver a 200 OK response to a Pipedream webhook endpoint getting hit. It can be a few seconds even on subsequent call (so perhaps not just cold start?). It is causing the calling application to thing the server is non-responsive and fail.
To add a bit more context, this is mainly (but not exclusively) when using a custom response step or a code step with a response immediately following the trigger step.
Hey , what’s the configured memory for your workflow?
It was at 256, but even bumped up to 512 it was taking 1.5-7 seconds to return a custom response.
Is the total complexity of the workflow part of the initial load/run time even for earlier steps? I am using conditional logic that I can likely strip out and make into different endpoints need be.
Oh okay, I asked because increasing it to at least 512 MB should reduce the overall execution time, especially for the first steps
Yeah, it didn’t seem to help.
Yea there is a jump in time execution time from the trigger to the rest of the steps in the workflow
The cold starts definitely make a difference
Does the entire workflow impact that jump, or is it always there?
It’s always there since triggers are a separate entity from workflows
Ah, shoot. 
Can you try setting your workflow at 512 MB and see if it helps mid term?
I did test that, I couldn’t get it reliably under 1.5 seconds.
Even on a warm execution?
It is a client instance, and they are not paying for Business, so I can’t guarantee it is warm, but rapidly hitting it in postman will give me a better number, but not consistently.
Redeploying with 1024 to test.
First hit:
Second:
Thanks for trying that