【问题标题】:How to debug slow start-up time for SQLAlchemy queries?如何调试 SQLAlchemy 查询的慢启动时间?
【发布时间】:2016-01-17 22:25:01
【问题描述】:

我正在尝试诊断我的应用程序在执行 SQL Alchemy 查询时花费的时间。我观察到执行查询和 SQLAlchemy 事务开始之间有 300 毫秒的间隔。在此时间间隔内,没有日志可以报告幕后发生的事情。我有以下 sn-p 它创建一个新的作用域会话,然后使用会话通过主键查找项目。此操作大约需要 500 毫秒。

有人能建议我如何加快查找速度吗?开始执行查询所需的 375 毫秒是我真正关心的地方。

函数sn-p:

def review_item(review_id):
    """Review a specific item."""        
    logger.info('Creating a new DB session')
    session = m.DBSession()
    logger.debug('Session created')

    logger.info('Building query at %s', review_id, datetime.now())
    qry = session.query(m.Result).filter_by(image_id=review_id)
    logger.info('Running query')
    item = qry.one()
    logger.info('Retrieved item %s at %s', item, datetime.now())

    return item

我看到以下日志输出:

2015-10-19 13:51:06,874 INFO  [treachery.views][waitress] Creating a new DB session
2015-10-19 13:51:06,874 DEBUG [treachery.views][waitress] Session created
2015-10-19 13:51:06,875 INFO  [treachery.views][waitress] Building query at 2015-10-19 13:51:06.875089
2015-10-19 13:51:06,875 INFO  [treachery.views][waitress] Running query
2015-10-19 13:51:07,261 INFO  [sqlalchemy.engine.base.Engine][waitress] BEGIN (implicit)
2015-10-19 13:51:07,262 INFO  [sqlalchemy.engine.base.Engine][waitress] SELECT result.image_id AS result_image_id, result.tag_classes AS result_tag_classes, result.tag_probs AS result_tag_probs 
 FROM result 
 WHERE result.image_id = %(image_id_1)s
2015-10-19 13:51:07,262 INFO  [sqlalchemy.engine.base.Engine][waitress] {'image_id_1': u'2015/05/e1f04824d496457cb74b668976b991ef.jpeg'}
2015-10-19 13:51:07,372 DEBUG [sqlalchemy.engine.base.Engine][waitress] Col ('result_image_id', 'result_tag_classes', 'result_tag_probs')
2015-10-19 13:51:07,373 DEBUG [sqlalchemy.engine.base.Engine][waitress] Row (u'2015/05/e1f04824d496457cb74b668976b991ef.jpeg', [u'nobody', u'painting', u'decoration', u'indoors', u'food', u'pattern', u'frame', u'one', u'travel', u'illustration', u'hanging', u'wood', u'background', u'people', u'wall', u'table', u'design', u'exhibition', u'house', u'flower'], [0.989168643951416, 0.975763559341431, 0.96831738948822, 0.952613711357117, 0.945497691631317, 0.941344261169434, 0.932282328605652, 0.928139090538025, 0.926733613014221, 0.912606000900269, 0.883346319198608, 0.875022172927856, 0.871710419654846, 0.865160286426544, 0.86181652545929, 0.821693539619446, 0.810265898704529, 0.798673629760742, 0.796967625617981, 0.789543986320496])
2015-10-19 13:51:07,373 DEBUG [treachery.views][waitress] Retrieved item <treachery.models.Result object at 0x7f82b409a250> at 2015-10-19 13:51:07.373463

当查询开始执行时,观察日志行“正在运行的查询”和“开始(隐式)”日志行之间的长时间延迟(几乎 400 毫秒)。

【问题讨论】:

  • image_id 上有索引吗?
  • 是的,有。它是一个外键并且有一个索引:btree (image_id COLLATE pg_catalog."default" varchar_pattern_ops)

标签: python mysql performance orm sqlalchemy


【解决方案1】:

SQLAlchemy 延迟连接到数据库,所以如果上面的代码是应用程序中运行的第一个 SQL 查询,那么它需要创建一个新连接,这对于许多 RDBMS 来说是一个非常慢的操作。

我的猜测是正确的,那么对同一函数的后续调用不应该有 400 毫秒的延迟。

这里有一个question at serverfault 讨论 MySQL 打开新连接缓慢的各种原因。

【讨论】:

  • 谢谢!我也注意到了这一点。 SQLAlchemy 运行了几个查询——可能是为了校准数据库实例。我首先运行了几个查询以使引擎预热,然后运行此查询。
猜你喜欢
  • 1970-01-01
  • 2011-08-04
  • 2011-03-16
  • 2022-01-01
  • 2014-07-09
  • 1970-01-01
  • 1970-01-01
  • 2010-11-28
  • 1970-01-01
相关资源
最近更新 更多