冷启动确实卡死了，目测好多次 30 秒内无反应的，太 tm 的烦人了，放在后台又瞎唤醒淘系的一大片 app，更 tm 的卡的要死，支付宝这些产品经理啊，今年好不容易看起来靠谱多了，现在又开始傻叉了，23333

3m 耳罩不错，隔音效果很明显

snowflake 麻烦是节点位太小了，很难自动根据当前部署机器和进程信息自动生成节点 id，在自动化分布式部署的时候可能会很麻烦

mongodb 的 bson objectid 是 12 自己，base64 编码之后就是 16 字符啊，这就好了啊

调试工具条性能工具里可以看得到每个操作的重排重绘信息，我记得 w3c 的官方文档也写了每个 css 属性对重排重绘的影响了吧

一般来来说如果 display:none 之后影响其他元素的高度之类的就会产生重排，重绘基本都会有吧

vue 和微信小程序 if 这个在映射到 dom 之后使用的是添加和删除标签的操作，那么肯定会触发浏览器重新渲染了

chrome 调试工具条似乎有工具可以标记颜色显示网页各部分渲染，可以看出是否有重复渲染，想不起来那个工具了

显然是需要在任务执行过程中不断检查结束任务条件是否达成，是则退出
或者，任务启动之后再创建一个线程来执行实际任务，主线程则不断检查停止标记是否达成，是则停止任务线程执行

今年好像限流很厉害，所以，其实都只是你在自言自语，根本没人看得到，23333~

事务没调好？单机的怎么会有问题！

@elvisyao #6 bbr 写反了吧，我怎么记得当时 google 出这个的时候，文档写的是改善高延迟下带宽利用率，抗丢包
实际使用似乎也是这样啊，感觉特别是抗丢包的效果还是很明显的

dns 都解析不了。。

抓包之后你会发现，tcp 连接建立正常，但是 ssl client hello 包无响应，应该是 gfw 的问题，本来还一直想是用香港套路云可以不用备案的，可是常常不能用，好坑的，简直了

@1239305697 #5 bindgetuserinfo="bindgetuserinfo"这个定义的不就是回调函数么，哥

其实时间年月日时分秒对人是很容易记的了，每个人都自然对时间自然有理解，管理上也很友好，本身就是时序的，后面加上全局计数器、随机数或者用户 id 都行，都可以在短时间多机快速生成很多订单好
有做法也可以年月日时分秒+1 字节机器 ID+2 字节进程 ID+1 字节进程内计数器，四字节转 10 个数字，一般就可以快速生成订单号了吧

如果是 buffer cursor 的话，那么 execute 阶段就已经完成数据加载到内存解析完成了吧
而且事实上 cx_oracle 是用 c 写的啊，和 python 语言性能并未有直接关系
试过 pymysql 纯 python 写的从 mysql 取出百万条数据也不是很慢的吧

@Kongtou #33 但是很不幸，世界却因这些玩具得到了飞速发展，太纠结所谓语言感觉就像古时读书人的矫情一样，何苦呢，汇编有汇编的牛逼，js 有 js 的优势，人尽其才，物尽其用不好么

说性能的，性能这是问题么？！不管怎么每秒 1000 的 qps 的肯定可以的，就说你们有多少服务是可以到这个级别的
弱类型语言哪不靠谱了，要说安全问题，现在大量 web 开发的语言层面的说安全问题这是个问题么，更小白的安全问题多了去了
而且开发速度快，迭代快，哪不好了

nodejs 的问题分明是包依赖太多，而且质量很难一致，在没有 await 之前，难以同步化处理业务流程和异常难以处理才是问题吧

首先 MySQLdb 并不是线程安全的，而且 mysql 协议是 request respond 模式的，并不能在上一个查询未完成之前发送下一个查询请求，这种基础问题随便一查都知道的吧，多线程不加锁挂才是正常的

你可以想一下，很多年以前多么牛逼高大上的云计算到现在差不多大分部需求都是云主机的

而且 setTimeout 实际是有最小延时时间的，并不能是 0，好像是 4ms 吧