粗略地看了一下，你这段 SQL 是分日期统计吧。那么就分表计算啊，每天跑定时任务，按小时，天，月分别建汇总表。你分析起来就简单了啦

@xjlnjut730 那也只能说 chromedriver 是那样做，geckodriver 可不是

@wingkou 你说这些没用的，你还是去网关跟 Ubuntu 两个地方分别抓一下包看看到底什么情况，看看到底包在哪个地方丢

@ClericPy 我理解你的说法。说 selenium 限制多的，还有就是无法对特定资源进行封堵。
ua 跟代理我看谷歌内部的确不想搞，因为别人没这个需求。IP 有 A 段，UA 公信性好。所以我真的建议改源代码还快点。不过的确需要功力

@nullboy 你先看看别人官方说的集群跟你讲的这些。跑久一点看看情况，当然没有问题的话，你可以继续用。

至于 ua 跟代理，你可以看看题主是怎么问的，然后你再回答。我只能说不是每个人都会觉得杀掉浏览器重启这样一个方式叫动态切换。

@xjlnjut730 selenium 是 webdriver，那是另外一套协议。你不安装对应浏览器的 webdriver 驱动根本没法控制。cdp 跟 webdriver 不是一套协议。
现在主要是谷歌更新了了 chrome 的 headless 模式，加上 cdp，能控制爬虫的精度更高了。

@ClericPy 至于代理你还是在网关之类的地方搞吧。代理价 UA 什么的都是爬虫大忌，谷歌作为一个搜索引擎，他们都是认为爬虫不应该动态改 UA 跟代理去爬不让你爬的东西。怎么可能有接口。
当然你加一个接口应该也不难，自己动手去改一个 chromium，加一个接口呗，如果你能改得动的话，加 Java Applet 检测欺骗都可以。

还在用 selenium 的肯定是很水的教程，万能不更新而已。selenium 各种功能限制，部署困难。最关键的是，占用资源太多，很多个版本都有内存泄露问题。

type 是 metaclass，在以前的版本之前不是所有类都是新式类，所以会出现非 object 派生的类。type 跟 object 的确是不存在先后顺序的，类似的问题在 Java 界也出现，都是靠底层 VM 初始化的时候产生。
你可以简单的理解成，神说要有光，于是便有了光

@YenvY 一般人是感觉不出 Ryzen 跟酷睿的差别的，要知道现在各类云内部都有上 AMD 的 CPU。不过具体一些特性，比如 avx512，那的确是 Intel 强，还有就是 mkl 之类 Intel 自己有投入的库。
一般都是没什么区别的，用 Ryzen 作为开发机的 CPU 完全可行。

@alfredsun realtime 的延迟应该是跟 rt 差不多的。一个是稳定版一个是最新版的区别吧。新的 rt 可能采取更加激进的调度算法，所以可能有设备不支持

@hanssx 现在我想起来了，我建议你还用 nmap 的 Python 封装库，而不是直接用 subprocess，这样就比较少一些问题，好像叫 Python-nmap，搜一下就可以了。钱就不需要了

@hanssx 不可以，可以的前提是你改得动网络请求的部分

@hanssx cpu 密集型是相对的，关键是你的任务类型不能堵塞整个处理逻辑，凡是耗时长的，不需要 IO 的任务都是 IO 密集型

看了一下你用 subprocess.Popen 去调用 nmap，你如果要改的话，请使用 gevent 的网络接口实现你 nmap 的功能，如果不会的话，此方法无解，你还是另寻他法吧。

\w*

有的，名校博士毕业证书就可以了。否则的话，看你所在公司以及岗位。当然你靠吹牛也不是不可能。考试认证是不可能考试的。本身该领域就属于前沿领域。方向对不对都不知道，怎么给你出题认证啊。大家都是靠刷论文跟学历

没记错的话，celery 自身实现是对 fork 之类有限制的，所以你不应该在任务里面进行类似 fork 之类的操作，线程 pthread_create 同理了。
而且线程的支持我记得已经被 celery 自身抛弃的，所以应该是有缺陷的，建议不使用线程。

根据我以前的做法，我一般都是将网络 IO 与逻辑处理分离。celery 对 gevent 跟进程支持都相当好，因此我会选用个 gevent 处理所有网络 IO （网络 IO，通过 IO 复用，几百万个任务都可以轻松搞定，前提是不能有任何 CPU 密集型处理）。然后通过跟进程型任务结合，组成流水线，在 celery 对应 chain 操作。那么就可以稳定地运行。

因为 gevent 是处理网络是不堵塞的，所以你还是可以继续发任务给该 worker

可以参考一下

@TangMonk pdb 是标准库的，不用额外安装

jit 需要内存。至于相同的功能这个说法我表示怀疑。
GC 其实跟内存用多少关系不大。

@dbskcnc golang 作者原先就吐槽 C++的编译速度，因此他们坚持不能降低编译速度这个逻辑是自洽的。当然大家觉得好不好就另外一说。

不是说 go team 的经验足就代表他们比提案者厉害，有压倒性优势。大家都是受现代编译语言影响的人，提案者可不单单代表自己的知识储备，他还受这个业界最新的 PL 研究，多年来的 PL 实践影响。因此片面说其他人水平不够高是让人难以理解的。

其实不要说那么多，就是他们的追求跟大众的追求不协调而已。他们追求编译快速，自己觉得简单使用的语言，逻辑自洽。但是这说出来大家能接受吗？语言动了根本追求，哪怕是能做啊，那不就打了自己的脸？这才是根本问题。