前几年学到的一点就是, 不是什么地方都能叫"单位"...

这么在乎价格成本的话... 白瓢免费代理吧, 选普匿和高匿的, 然后走生产者消费者模式, 慢慢抓慢慢跑

是说这个同事不重要呗?

各有偏重, 除非真的算法经验和工程科班都熟悉到一定程度, 不然直接下这种定论的我一般都说句有道理然后该干嘛干嘛去

就过往经验来说, 这种情况基本就是让你自己走了...

睡眠不足各种毛病都会有的, 买本 GTD 的书看看吧

一直用的 systemctl --user 倒是没遇到过, 话说不用 --user 的 config 有什么优缺点么

@fishCatcher
@czhfrank
之前看楼主不想留美... 以为回国读硕

难怪这么不想继续读书, 我又信息不对称了

每年的 Gartner 技术成熟度曲线


[狗头] 保命

能用钱解决的问题从来都是钱的问题, 而不是其他

简单的说, 百度的产品实在没有让我太依赖的, 也不是做的不好, 就是主观意识上不太想用, 现在百度知道上还几千财富留着帮别人下文档, 其他都在迁移

@FlyerWonder

第一份工作千万别去小作坊或者外包, 尤其是突然就创业的小团队, 就这么一句忠告, 直接影响到你未来的方向, 下一份工作的薪酬, 跳槽时候简历过审几率, 企业文化等工作习惯

既然家里面没有经济压力, 还是先观望一下, 可以自学深造积累一下基础和实践能力, 应届生面试没法问工作经历, 所以科班生会着重考察基本功和动手实践能力, 这方面多准备准备. 整个面试过程其实就是给用工方一个留你的理由

至于不想读书... 读研和读本其实天壤之别, 学士的任务几乎都是打基本功和看书学习, 而读研(硕博) 主要是科研类的方向, 是依靠之前学的东西做点成果出来, 比本科死读书的节奏好多了. 所以如果只是不想读书而不去读研, 可以换换思路, 写个爬虫把那些目标学校的硕导研究方向抓下来, 看看有没有你感兴趣的, 实在不感兴趣再放弃也不迟.

美国那边不熟悉, 认识的人在那边停工到上个月才勉强复工, 不过最近美国形势听说还是酋长拉选票或者转移注意故意做的事情, 再观望一下或者多找懂行的人了解一下比较好

综上, 信息不对称是选择恐惧症的根源之一

最近看多了水帖, 见到楼主逻辑这么清晰, 文字简练信息量大的主题居然还有点不习惯

美国现在是不是风向有点乱, 要不先等大选...? 疫情期间就业情形确实见仁见智还是慎重考虑一下, 一般成绩尚可的, 读个硕做点研究还算不错的选择, 不只是延缓就业, 可能找到自己喜欢的方向也会减掉迷茫

既然想落户上海, 就先不要着急确定工作, 对大多数人来说第一份工作对未来影响还是很大的. 几个建议就是, 你这种背景, 刚毕业不要走外包也不要盲目创业, 有华为 offer 继续找大厂问题不大, 找工作很多时候反而看的是运气, 现在的情形不好就沉住气继续找, 莽撞选择要不得

看到有几个回复挺反常识的, 提醒几个 Python 并发编程的常识问题吧

1. 线程开的越多, 执行起来就越快吗?

并不会.

一方面, 线程开太多, CPU 切换的成本会变高, 也就相对降低了 CPU 利用率, CPU 很多时间浪费在调度上而不是计算上. 有关怎么切换的, 可以随处找找 GIL 的文章, 不过还是不建议自己修改对应参数 setswitchinterval (旧版本的 setcheckinterval )
另一方面, 对爬虫来说, 如果连接速度靠谱的话, 有可能一个线程就跑满了带宽, 那开多线程除了让所有任务一起抢资源, 并不会降低总时长, 也就是常见场景: 为什么我开 5 线程比开 100 线程还快(或者差不多). 与普通程序不同, 爬虫程序传输数据一方面看你的带宽, 另一方面还特别看重目标服务器的负载能力.

2. 有一个比较合理的并发数量吗?

参考:
Python3 里面 ThreadPoolExecutor 的 max_workers 默认值是 (os.cpu_count() or 1) * 5
可以根据带宽使用率适当调整这个数值.
(另: 多进程 ProcessPoolExecutor 默认 max_workers 就是 os.cpu_count() or 1)


3. 不计带宽和 CPU 能力的情况下, 是不是线程开的越多, 速度越快?

也不完全是.

拿 Requests 库来举例, 它的 Session 默认连接池大小取决于 HTTPAdapter 对象的 pool_connections, 这个默认值 DEFAULT_POOLSIZE = 10
简单的说, 如果不修改 HTTPAdapter 连接池的大小, 那可能瓶颈基本限定在这里了. 至于有些人选择不用 Session 复用连接, 我举个例子算了: 之前抓某东的某数据, 复用连接的情况下速度比每次新建连接大概快了十几倍.

4. 是不是用协程就比线程快, 节省 CPU?

不一定.

协程提高的是 CPU 效率, 遇到高并发的抓取, 你会发现协程 CPU 一直 100%, 因为它真的很忙, 而多线程反而可能在 80~100% 波动. 至于速度, 简单的提个例子, falcon 那是相当擅长 Benchmark.

协程中最使我受益的并不是性能, 而是它属于随时可以 Cancel 的, 一个已经执行的线程, 想在外部杀死它简直太费劲了.

好久以前还看到有人在这里吐槽 Python 没有尾递归优化

@ochatokori 原生用 systemd 还好, cron 一开始用的舒服, 后来被同事东一块西一块还没注释的 cron 给玩死了... 虽然我上份工作用 supervisord + plan(Python 库, 定制 crontab 任务的) 做的通用脚本调度也能玩死不少交接的...

一两个任务, 服务器少的时候, crontab 用着还好, 但是考虑极限情况: 多账户, 多机器, 几百个任务... 这不叫运维了, 这叫防离职黑魔法

Talk is cheap, 试试就知道了

直接说结论:

1. 本次测试不记带宽发送本地端口的请求, 本地 server 使用 golang 默认的 net/http 简单实现的

2. 对比 httpx 协程和 requests 多线程, 二者都使用连接池复用连接. 前者比后者快了大概 20%(虽然后者被我负优化了...), 启用 uvloop 以后也没拉开太大差距.

3. 对比 aiohttp 和 requests, 不使用 uvloop 的时候前者是后者 3 倍, 开了 uvloop 大概 3068 qps, 是后者的 3.15 倍, 而 golang 内置的 net/http 测试也才 3300. 虽然很大因素是 aiohttp 内核很多地方使用 Cython 实现的...

4. 对比 windows vs linux, 前者是游戏本所以多核(但是只能用一个...), 后者在阿里云服务器上虽然单 CPU 但是有 uvloop 加成, 速度提高一倍

部分代码: https://github.com/ClericPy/torequests#benchmarks


一句话总结, 以上测试纯属娱乐不作数, 真想用快的, 就选 aiohttp 就好了

之前貌似还看到, 裸 uvloop 单核情况下和 golang 差不多

@s609926202 我就随口一问, 因为见过超过十次了... 在想是不是新的流行说法

反正定时任务尽量还是别用原生 crontab 了, 找个靠谱点的调度后台算了, 最近也在调研处理定时任务流的, 在 azkaban 和 airflow 里面转悠