CODEWITHSUNDEEP
pythongoogle-app-engine
Raghu P
Raghu P

Reputation: 68

What determines start up time of dynamic instance and can it vary between weeks if code is same

We are facing strange issue in our application, where we are getting error as:-

Request was aborted after waiting too long to attempt to service your request.

Earlier we were able to scale well with same number of idle instances, but now we are not and we have not changed anything code wise that could impact start up time. But now we are receiving timeout.

Upvotes: 3

Views: 155

Answers (1)

Dan Cornilescu
Dan Cornilescu

Reputation: 39814

With python it's possible to significantly improve instance startup time depending on your app's code organisation.

Lazy loading of request handler code only loads at instance startup the python file containing the handler for the actual request triggering the instance start, not the entire app code. The handler code can thus be separated from the module's main file mentioned in the module's .yaml. In as many file as you want, even a single handler per file.

For example in a particular module's module_blah.py file you could have something like this loading only the respective file1.py, file2.py or rare.py files in addition to the module_blah.py file (which is loaded based on the module's .yaml file) and only if/when the respective paths are requested:

app = webapp2.WSGIApplication([
    ('/path1', 'file1.HandlerOne'),     # loads file1.py
    ('/path2', 'file2.HandlerTwo'),     # loads file2.py
    ('/pathX', 'rare.RareHandlerOne'),  # loads rare.py
    ('/pathY', 'rare.RareHandlerTwo'),  # loads rare.py
    ('/.*', ModuleBlahHandlerX)         # already loaded module_blah.py
], debug=True, config=apart_config)

You can also place the necessary import statements for heavier/3rd party libraries inside the methods using them instead of at the top of the files, which also loads those files only when the respected methods are invoked.

The drawback is that the response time for some requests may occasionally see some peaks - when the respective code is loaded, on demand, in the instances handling those requests. Subsequent requests handled by the same instances will be faster since the code is already loaded.

I guess changes in the SDK or in the operating conditions of the GAE infra (overall load balancing activity, shorter or longer transients due to maintenace, outages, etc) at certain times may account for variations in the instances startup time, potentially causing the symptoms you describe if your instance's startup time was close enough to the maximum allowed. The techniques I described could help your app stay further away from that max, reducing the chances of hitting the problem.

Finally, configuring a more powerfull instance class would also speedup the instance startup time for the same app code.

Upvotes: 2

Related Questions