Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

增加在线查询超时时间配置,超时连接主动关闭 #125

Merged
merged 4 commits into from
Apr 14, 2019

Conversation

hhyo
Copy link
Owner

@hhyo hhyo commented Apr 14, 2019

相关issue : #100

  • 增加在线查询超时时间配置,超时连接主动关闭,新增配置项max_execution_time
    使用django_q的async_task去执行语句,并且同步等待执行结果,执行超时的语句会关闭连接
  • job模块修改为task以及部分变量调整

写下整个实现过程,有点懵

  • 第一种实现
    利用schedule,每次查询前增加一个定时执行的schedule,参数是当前engine的connection,到超时时间就执行engine.close()动作,如果在schedule调用task前就查询结束,则在查询结束后删除schedule。
    但是测试过程中发现django_q的schedule参数不支持对象,见ERROR invalid syntax (<unknown>, line 1) - while passing objects as arguments Koed00/django-q#170 只能是str或者int,
  • 第二种实现
    依然利用schedule,查询前获取thread_id,使用实例id和thread_id作为常量传入,最后执行kill或者其他命令来终止线程,可以正常处理,但是问题在于mysql有kill的方法,其他数据库不一定,这就需要每种数据库都写一个对应的方法,并且在执行前就需要判断实例类型了,emmm 貌似才剥离这一块
  • 第三种实现
    也就是目前提交的使用task的方式,这个方式有明显的弊端,就是fetch的方法是到数据库去轮询,而且查询频率很高,可能需要定期清空task表会比较好

或者 @LeoQuote 是否还有其他更好的实现

@hhyo hhyo requested a review from LeoQuote April 14, 2019 08:48
@codecov
Copy link

codecov bot commented Apr 14, 2019

Codecov Report

Merging #125 into master will increase coverage by 0.08%.
The diff coverage is 49.35%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #125      +/-   ##
==========================================
+ Coverage   73.31%   73.39%   +0.08%     
==========================================
  Files          61       61              
  Lines        6497     6507      +10     
==========================================
+ Hits         4763     4776      +13     
+ Misses       1734     1731       -3
Impacted Files Coverage Δ
sql/tests.py 100% <100%> (ø) ⬆️
sql/urls.py 100% <100%> (ø) ⬆️
sql/sql_workflow.py 57.08% <20%> (-0.19%) ⬇️
sql/utils/tasks.py 33.33% <33.33%> (ø)
sql/query.py 52.71% <41.17%> (+5.6%) ⬆️
sql/views.py 37.86% <50%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2edf460...f36e9f1. Read the comment docs.

Copy link
Collaborator

@LeoQuote LeoQuote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

天呐你都做了,而我还在摸鱼!!! 那个报错的提示这么写吧:

查询时间超过 XX 秒,已被主动终止,请优化语句。

另外查询的exception 是不是没有写? 可以再加一个 if result.success 不知道success 依然前端报错,具体的traceback可以传前端,也可以只打日志。

@LeoQuote
Copy link
Collaborator

我认为第三种可以接受,因为查询频率高实际上查询的是redis ? 查询的效率应该可以接受。

另外如果实在频率不能接受的话可以自己实现轮询查询,自己在代码中sleep即可。(挺丑哈哈哈

@hhyo
Copy link
Owner Author

hhyo commented Apr 14, 2019

我认为第三种可以接受,因为查询频率高实际上查询的是redis ? 查询的效率应该可以接受。

另外如果实在频率不能接受的话可以自己实现轮询查询,自己在代码中sleep即可。(挺丑哈哈哈

从debug来看查的是mysql

@LeoQuote
Copy link
Collaborator

查到有一个cached参数,可以让djangoQ在缓存中查询结果,我觉得可以考虑这个做。

https://django-q.readthedocs.io/en/latest/tasks.html

@hhyo
Copy link
Owner Author

hhyo commented Apr 14, 2019

查到有一个cached参数,可以让djangoQ在缓存中查询结果,我觉得可以考虑这个做。

https://django-q.readthedocs.io/en/latest/tasks.html

已修改,push巨慢

@hhyo hhyo merged commit ddfa689 into master Apr 14, 2019
@hhyo hhyo deleted the max_execution_time branch April 14, 2019 16:00
@hhyo
Copy link
Owner Author

hhyo commented Apr 14, 2019

合了发布1.5.0

@LeoQuote
Copy link
Collaborator

棒👍

@jerryhu1234
Copy link
Contributor

这里虽然提示是主动断开了连接,我发现1.6版本,sql还是在数据库上在跑的??

@LeoQuote
Copy link
Collaborator

这里虽然提示是主动断开了连接,我发现1.6版本,sql还是在数据库上在跑的??

因为设置了timeout参数, 会结束掉python进程, 但是sql可能确实还在服务器上跑, 这块确实有优化空间

@hhyo
Copy link
Owner Author

hhyo commented May 29, 2019

这一块之前的测试逻辑是这样

  • 设置超时时间为10
  • 在线查询执行select sleep(30)

10s后查询会被终止,并且mysql相应的进程也会终止,不清楚@jerryhu1234 遇到的是什么样的场景

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants