很困难，因为你能设置代理就意味着你能劫持用户的数据，chromium 原则上不允许这种做法，实际上很多安卓版本的 webview 需要 hack 的办法解决，但是兼容性成问题

这个题目很多有问题吧，那个过滤 js 的只是过滤 script 标签本身就是错的；那个秒杀系统更扯淡，要 2 个 tcp 来回而且对单 uid 重复提交没有过滤，你就算用 redis 集群所有的请求都打到一个 redis 的 list 上能撑住么……

这种不知道原理想当然的活很麻烦。。。关系数据库数据是落地到硬盘的，内存当然可以做缓存，只有你缓存多少数据随便。我不认为你迁移到所谓的内存数据库性能会有质的提高

@ming 你咋不说 google 用 py 呢？我不信 paypal 敢把钱交易的东西放 node 里

那就回到上个世纪吧，看你在没 WiFi 的环境中能撑多久

@leandre 人家 camera360 追查内存泄漏都追查到 php 源码上了，内存泄露这东西很难很难
至于 max_request 问题，如果不是协程的方法没啥问题，如果是的话你退出的话别的还没有完成请求的携程就也会马上退出，swoole 之前没有提供原生的支持，需要框架自己逻辑通知 swoole 停止分配 http 请求过来然后等待所有请求完成后再重启该进程

都写了那么多 print 了，怎么改成 logger 啊
我给你推荐一门语言 javascript，那个函数随便你改

python test.py 2>&1 | tee -a $log_file
就这么简单，非侵入式

@sagaxu 实际上内存泄露很难避免，也很难排查，不说一水的扩张有泄露，很多 composer 下的库是为 php-fpm 写的泄露很难做好，比如我就简单操作个 redis 遍历几 kw 次就能观测到几个 g 的泄露，每次漏个几十字节啥的

又挂了

与其说不期待不如说期望值不高，比较协程就是腾讯贡献给 swoole 的，在包装 tcp 库的时候直观了很多，半协程理解起来挺吃力的

目前做的最好的是有赞的 zanphp，不过是基于 yield 的半协程，实际上目前比较成熟的都半协程。。。腾讯似乎最近要开源一个基于 swoole2 的协程版本出来，不过我完全不期待。。。。

用 guzzle 的并发，它包装的 multi_curl_*接口

联通+1

这几天出门陌生城市旅行，被这个设计搞得很烦
那些说指南针传感器不准的，你下载一个指南针 app 看看准不准

没法断点调试，不可能吧