我在module.yaml
中有这个配置runtime: python27
api_version: 1
instance_class: F2
threadsafe: true
automatic_scaling:
min_idle_instances: automatic
max_idle_instances: 8
min_pending_latency: 0.25s
max_pending_latency: automatic
max_concurrent_requests: 80
在控制台中,我看到这样的数字:
QPS* Latency* Requests Errors Age Memory App Engine Rel. Availability
8.730 113.5 ms 12621 0 1:48:25 67.9 MBytes 1.9.27 Resident
14.142 76.7 ms 12543 0 1:48:26 79.8 MBytes 1.9.27 Resident
13.411 74.3 ms 12753 0 1:48:26 96.4 MBytes 1.9.27 Resident
如果您将QPS(每秒查询数)乘以Latency(转换为秒数):
我每天多次重复同样的练习,在所有情况下,右边的最后一个数字非常接近于1个查询。
所以我怀疑同一个实例是否能够并行处理查询。您可以在平均延迟中看到我的流程非常快,当我需要做很长时间的工作时,该流程使用任务队列。我不在此模块中使用异步进程。我读到当你有一个等待urlfetch响应的空闲进程时,它将是另一个python线程/请求并行执行的机会,但不是我的情况。
官方文档在这方面没有详细说明,只是声明:
使用并发请求
默认情况下,App Engine会将请求串行发送到给定的Web服务器。您可以通过将线程安全元素添加到app.yaml来配置App Engine以发送多个并行请求。
threadsafe:true
我是否需要设置另一个参数或使用特殊库来允许多个请求在相同的实例中并行执行?对于上面显示的QPS数字,平均CPU利用率在15%到25%之间,因此可以并行运行至少3个请求的空间(没有足够分析的个人估算)
谢谢!
答案 0 :(得分:1)
使用低延迟请求不是应用程序多线程的好指标。处理请求的一部分发生在应用程序本身之外的GAE infra(例如,路由到应用程序)或应用程序内部但在非线程区域。对于低延迟请求,非线程百分比可能很大,使结果偏差并可能导致错误的结论。
要检查并行请求处理,我建议使用不使用潜在速率限制GAE服务的高延迟请求。例如,尝试让您的请求处理程序执行普通的python处理,或者只是在回复之前休眠40-50秒,以便清楚地看到请求是否真的是并行处理。