Python应用引擎webapp2慢到rou

Question

我有一个Python应用程序引擎应用程序，每天可以处理大约300万个请求。我正试图优化应用程序，以节省我可笑地膨胀的托管费用。你知道吗

November, App Engine Frontend Instances: 12924.391 Hours, $604.22

我将请求处理归结为一些memcached调用，但现在我注意到，通常需要20毫秒，有时甚至需要166毫秒，webapp2才能将请求传递给我。你知道吗

在下面的图片中，你可以看到一条显示“Post”的轨迹，发生在166ms

这是服务于此的代码。你知道吗

import logging
logging.info("main.py logging imported")
from imports import *
from handlers import *
logging.info("completed importing others")

class Main(webapp.RequestHandler):
    def post(self):
        logging.info("Post")
        self.get()


...

app = webapp.WSGIApplication(
    [
     ('/.*', Main)
    ],
    debug=False
)

我试过什么？

我已经启用了threadsafe，所以任何导入都不应该在请求被服务之前发生。为了确保，我还添加了日志记录，以查看导入何时发生，正如您所看到的，并不是每个请求都进行了导入。你知道吗

更多信息

延迟是否低并不重要，只是为了节省托管费用。即使只有1分钟的响应时间（请求是一个API webhook），只要它不算前端实例时间就可以了！你知道吗

如果相关的话，这是我的开始附录yaml. 你知道吗

application: coolestsports-hrd
version: 1
runtime: python27
threadsafe: yes
api_version: 1
automatic_scaling:
  min_idle_instances: 1
  min_pending_latency: 1000ms

Answer 1

如果将instance hours标签保持在较低的水平比将请求延迟保持在较低的水平更有意义，那么您可以放弃自动伸缩，转而使用基本伸缩。从Scaling types and instance classes：

Basic Scaling

A service with basic scaling will create an instance when the application receives a request. The instance will be turned down when the app becomes idle. Basic scaling is ideal for work that is intermittent or driven by user activity.

Automatic Scaling

Automatic scaling is based on request rate, response latencies, and other application metrics.

自动缩放以更好的用户体验为目标，可以根据传入的流量模式启动大量实例。你知道吗

有config parameters可用于调整缩放行为，但对于自动缩放，根本没有限制并行运行的实例数的方法，这可能会导致实例时间的浪费。顺便说一句，您的min_idle_instances: 1将几乎一直保持实例的活动状态，几乎总是空闲的（其他实例将实际处理大部分请求）。你知道吗

另一方面，基本扩展有一个max_instances配置，可以用来有效地限制bill的实例小时数：

max_instances

Required. The maximum number of instances for App Engine to create for this service version. This is useful to limit the costs of a service.