@monetto 看这个意思是... flask 初始化 app 还不够, 还要启动, 并且用户发来请求之前, 那 before_app_first_request 然后自己 Requests 自己不够么, 写个能阻塞的就够了吧. 这还不行只能去 flask 源码里找钩子了... 你要的 startup event listener 我至少在 stackoverflow 和 flask 官方 Github 都没看到

没见过... 只知道有个第一次请求前的回调 before_app_first_request -> before_first_request_funcs. 反正 signals 里没看到
Sanic 和 starlette 那些协程库倒是可以添加 after_server_start 事件绑定...
什么任务不能初始化 App 的时候直接做好准备, 再去启动...

为什么我脑子里突然闪出一个画面:
某 TZN 员工因为电脑只连内网, 所以用手机去 google 问题, 再把几百行代码一个字一个字码到显示器上.......

我的也是吃了一年灰才捡起来的, 为了它还花了三四天写了个 watchdog 用来把我追的剧抓来转 RSS... 全程没什么技术含量, 也就是在网页端填两句 css / regex / Jsonpath 就能定位到要监视的元素, 然后发生改变就 RSS 看到了, 或者 callback 里套上那个 server 酱发给微信, 然而....... 我又不用微信........

目前来说除了吃灰, 也就是做点报警提醒什么的了, 挖矿也挖不动

太长了... 挣钱机会留给学生吧...

celery 自从在公司里见识过内存泄漏的小坑以后, 基本不敢碰了

不过提到僵尸进程, 感觉有点像我以前碰到过的情况, 先确认下是僵尸进程还是孤儿进程, 两者不太一样.

我最后是用 psutil 粗暴查杀的... 不过之前用的方法可以给你参考下:

1. close_fds 参数
2. kill 子进程的时候一定要 wait, wait 超时(Python3 才有超时... Python2 自己用 timer 做)再去强杀
3. 考虑子进程里带上个 timer kill self 吧, 这个方法最蠢又最简单... 俗称蠢强蠢强的...

@sunmker
AC 自动机有现成的用 C 实现的, 直接 pip 装上用就好了, 自己写费那劲又不如 C 的快. 它的好处就是, blacklist 特别大的情况下, 性能非常不错, 做敏感词过滤 /替换的时候用的很爽.

语法糖的话, 目测一般就是用函数式那俩 all 和 any, 以及 not any. 因为 Python3 里面这俩货都改生成器了, 所以内存和速度都有点优化

零宽断言不见得特别有用, 不过好玩啊
import re

# 都存在
print(re.search(r'^(?=.*中文)(?=.*英语).*$', '英语不如中文不'))
print(re.search(r'^(?=.*中文)(?=.*英语).*$', '英语不如不'))
print(re.search(r'^(?=.*中文)(?=.*英语).*$', '不如不'))
# <re.Match object; span=(0, 7), match='英语不如中文不'>
# None
# None
# 都不存在
print(re.search(r'^(?!.*中文)(?!.*英语).*$', '英语不如中文不'))
print(re.search(r'^(?!.*中文)(?!.*英语).*$', '英语不如不'))
print(re.search(r'^(?!.*中文)(?!.*英语).*$', '不如不'))
# None
# None
# <re.Match object; span=(0, 3), match='不如不'>

哈哈, 你拿一个 C 写的东西和一个 py 写的东西怎么比...
很多问题等你多用几年就自然理解了, 比性能是不能跨语言比的, 要比也得 lxml 和 re 比

不过算法不同, 就算用 lxml, Xpath 解析也比 re 慢的, 光假装构建个 DOM 就费老劲了, 别忘了 Element 还有一大堆绑定方法, 用途不一样, 就别和性能较劲了

@w985341237 好吧, 我当时倒是还真没用 uwsgi... 那次倒是让我长了个记性, 以后这种长耗时任务, 基本都丢消息队列做了, 走 SSE 从服务器推事件来判断.

https://github.com/MagicStack/uvloop
这是 uvloop 的 Github, 发现他们测的比我的结果好多了... 至少提高一倍速度

拖 uvloop 的 fu, starlette 框架性能落后 golang 没其他框架落后那么远, 也就慢个两倍左右...

@tu7jako 不做底层开发不用管 uvloop 源码和使用, 无脑 asyncio.set_event_loop_policy 就够了, 它是向 asyncio 协议兼容的, 除了 Windows, 其他系统随便开. 就我随手做的压测显示, 高并发协程能比默认那个提高 20% 左右

nginx 默认 60 秒的 timeout 以前也遇到过, 后来要么改走 WebSocket, 要么改用消息队列, 目前反正我配置的几个地方, 结合 stackoverflow 上学的配置, 都没什么用

简简单单一句话:
服务里禁用以后, 有个恢复选项卡, 你看看是不是里面有自动重启, 关掉

@ottf1225
@anguiao

棒! 就是要这个!!!!!!!!!!
tampermonkey
adblock
什么的就够了, 哈哈, 完美

@anguiao 凉凉夜色, 劝退告辞. 找个不番茄能直接下载扩展的安全第三方都费劲, 也不知道 APKPure App 能解决番茄问题么, 先不管了, 一个半成品, 抛开 chrome account, 还不如直接 chromium

你 sqlalchemy 的 driver 用的是 pure Python 的还是有 C 加速的, 后者会在 gevent 里无法打猴子补丁导致 block, 如果是纯 Python 的 pymysql 的话, 这玩意性能你就算使用了各种事务连接池合并提交什么的操作, 性能也很差的; 再加上 sqlalchemy 本身也不是以性能出名的

对你目前架构来说, 数据库操作想提速试试走消息队列吧

都用上 Python 了, 而且还不用 asyncio + uvloop, 就别指望性能有多好看了..

至于 celery, 不管是 redis 还是 rabbitmq, 我只评价一句: 又慢又占内存.

另: 如果是 Python2, 请无视我上面所有话. Python2 和 Python3 在同步框架里, 除了 falcon , 其他性能都不够看

@shadowwalker2644 好的感谢, 这方面信息不知道从哪看, 那我再等等吧. 只希望别用微软那个内置的 app store... 能独立出个网站就好

想推荐给不懂电脑的那些朋友, 之前让他们用 chrome, 他们又没法去外面的市场下扩展, edge 有什么办法下扩展么, 现在那些民间的都开始扫码下载了...

@Achilless 我居然没收到提醒有人回复我...

这估计和 go 没什么关系, 对 goroutine 来说 10 个和 100 个差别不该这么大, 主要开销还是在服务端的样子, 服务端扛不住太高并发, 而不是本地 CPU 扛不住

一楼你没带狗头, 就显得不像段子像真事了

我以前听过一个让我震惊很久的设计思想: 只要你的软件够慢, 用户留存时间就会增长.