Regarding the 1st issue, my first guess is that it could be the fetching of the bundle taking that long. Can you set your log_level to debug, and restart the gateway? Please share the full gateway logs from its startup.
The second one - error closing file - appears to be site-specific as you’ve found that it’s not the case with docker-compose. If everything works well, you might be able to ignore it. For now, let’s focus on the first issue.
This is a really difficult question to help with without access to Cloudrun. The only things I can suggest are:
Running the gateway with profiling enabled and capturing different profiles to see what’s happening during the time it’s paused (if possible). While pprof does produce a web interface, a better way to download profiles for analysis is like thiswget -O profile.dmp --no-check-certificate https://gaewayURL/debug/pprof/profile?seconds=2 The profile can then be analysed using https://pprofweb.evanjones.ca/
Building and running an instrumented version of the gateway to try and see where it’s hanging. What I mean is just putting log statements to try and track what the gateway is up to.
Using something like Delve to do an interactive debug of the running process and step through what’s happening. I’d suggest setting a breakpoint here and stepping forward from that
i have a feeling tyk doesn’t actually load the api module until the first time the path is called
This isn’t the case. Tyk loads all the APIs and policies during startup (or hot reload) and activates them all at the same time.
@zye-carma did you ever get this issue resolved. We are interested in using cloudrun as well to run serverless instance of tyk and interested to see if you were successful in the end?