@htedsv 我会早回酒店的

@233 竟然这样，还好我和我媳妇目前没有火车夜车的计划，那地铁和公交呢，有啥安全建议么？

这得看具体app了吧，我记得手机从icloud恢复后，微信的登陆要自己填吧，你可以填两个一样的，或者不一样的。。。记不清了有点。。

可以试试打电话的时候去拍照，看看有没有拍照声，以前玩sony的手机就是这样的。。。

补充下，我搞错了点，%CPU 下面那个数已经是总的 CPU thread 利用率的和了，横条上面的80% ~ 90% 是所有程序的效果，然后 mysql 在测试 workload 的情况下，只把一个 thread 跑了 6 ~ 9%，也就是说mysql自己还没到瓶颈（因为 disk util 也就在 5 ~ 8）

@est okay，mark下，回去对比下

@plprapper 哪个cloud?

@imskull 数据都有备份的

多打听下那些打比赛的在哪练，绝对有气氛，而且你态度诚恳的话，还能从他们那学到好多东西

分别测下并发的workload就行了

看到微博大户转发你们纵向scaling的文章了，现在仍然在招人窗口期？

楼主测的什么case？

@mengskysama

eventlet 默认是 epoll，当然这个我可以改，但是

1. 0.2s
2. 0.2s
3. 15s
4. 0.2s

这个现象里面的3，就不理解了

@leyle
100次请求是实际的，25s和35s是在主贴里大概描述的，顺序的情况下都0.02s左右完成，再优化是之后的任务了，不过千分之一秒这个目标不错，自己之前没啥概念

我遇到的问题还是如之前所说，并发的时候（哪怕并发只有5）会出现诡异情况：
1. 0.2s
2. 0.2s
3. 15s
4. 0.2s
...

python的trace结果是select.epoll.poll总耗时太长（顺序的总耗时3s左右，5并发100总请求的情况都有50s了）

正在用大家意见调整mysql到nonblocking再测

@nybux

> mysql调用要调度到一个线程池里面

这句话的意思我的请假下既然没有 fork 出来的多进程（worker）了，那直接让访问的mysql的线程池化，从而加速处理？

@reusFork

另外，用 python 的 trace 模块统计的时候，除了 select.epoll.poll 这个地方，其他函数的总时间统计在并发和顺序的情况下没有多大差别

@reusFork

怀疑到 epoll 是因为，用 python 的 trace 模块追踪 server 这块的时候，发现消耗时间最多的是：

.... 56.894 .... {method 'poll' of 'select.epoll' objects}

56秒那个是这段测试时间，跑 select.epoll.poll 这里总的消耗时间（平均的 * 次数）

在并发5，请求 100 次的时候 epoll.poll 一共消耗了 56 秒

但是顺序请求 100 次的时候，这里只有 3 秒多（另外一个不同时，这个方法被 call 的次数在鬓发的时候 2w 到 4w 不等，顺序的时候，只有 1w；平均消耗时间，并发的时候是 0.03s，顺序的时候 0.00s 就是小于 0.005s）
（上文的 25s ~ 35s 只是举例子）

另外，select 模块的位置是 /usr/lib64/python2.6/lib-dynload/selectmodule.so

rpm -qf 这个文件发现这个位置的文件是来自于 python-libs 这个包

以上均是客观事实了，能帮我小分析下么 :)

@mengzhuo
@totoismi
@no13bus

最近有碰巧发现在开说说的那种情况下，from foo import bar 是可以的，所以猜下，应该是：

1. foo.bar 会去找 foo.__all__
2. from foo import bar 的时候先是通过 pythonpath 找到 foo，也就是一个目录，这个时候import bar，pythonpath 自然就包括了本地，即 ‘.’ 所以 from foo import bar 是可以的

这个是猜的，还没查询代码验证

@julyclyde 同感是 baidu 搜出来的。。。