替换PYTHON27/DLL/sqlite3.dll，想哪个就哪个

@mahone3297 写的测试是准确的，主要是读的，那个2.6GB的，读的时候还是已经有CACHE了

如果你CLIENT或VPS带宽没问题的话，的确可能遇到IO导致响应迟缓的情况。

我们有个FILE HTTP SERVER，那里SSH操作总会比其他机器缓慢，理论上带宽不是问题，因为是内网。
查过可能原因是IO中断导致，2.6.38内核据说能解决这个问题，另外DD算出来的IO速率可能受IO影响，因为IO操作如果内存够是直接读写内存的，我们128G内存DD也是在GB以上，其实都走内存。
从你阿里云的DD上看，基本走的磁盘，不妨留出更多空闲内存供CACHE。

@caizixian 好吧说错了，\r是回车，只要别\n就不会到新一行了，\r回车就是回到行首的意思

@caizixian

from time import sleep
import sys

for i in range(1000):
sys.stdout.write(str(i)+'\r')
sleep(0.1)

社保取不出来，估计是公司愿意不交社保（也不给个人缴那一份了），不过这查税就会有问题，一般公司不敢这么干。
公积金只要不在户籍所在地，非个别奇葩城市就可以取现。

socket.makefile
then readline

sys.stdout.write不回车就是刷新当前行

标题里的就是'\xb2\xe2\xca\xd4'就是GB2312编码的，加u在encode转换其实蛮诡异的，不过latin1还能encode说明Python根据OS环境做了些取舍，放在英文默认编码系统里肯定转不出来。

附言里是utf-8的，
print '\xe5\xbe\xae\xe4\xbf\xae'.decode('utf-8')即可。

\x出现在u''里表示的就不是byte而是等效于\u00XX，
比如u'\xe5\xbe\xae\xe4\xbf\xae'其实等于u'\u00e5\u00be\u00ae\u00e4\u00bf\u00ae'，这样表示的是unicode char table里的第XX位而不是字节，意义就全变了。

反正bytes出现在unicode str里实在诡异。

习惯XP/GNOME2的用MATE，习惯WIN7的用CINNAMON

关掉会导致STATIC FILE走CPU而不是DMA。
PRODUCTION环境建议nginx reload，只会reset worker进程

好吧楼主，我在WINDOWS机器上用VC无优化编的跑了7.4秒，O1优化3秒(O2就没跑)
MINGW加O2得12.167，奇怪的是LINUX GCC O2也得7.78

用ICC估计你的代码没有PRINT，直接跑了0秒，然后把你注释掉的写文件开启成PRINT后，结果是：
99000 0.000000026
99100 0.000000093
99200 0.000000212
99300 0.000000033
99400 0.000000212
99500 0.000000093
99600 0.000000301
99700 0.000000033
99800 0.000000026
99900 0.000000301
100000 0.000000146
2.845000000

加/fast后输出到NULL后终于到2.194000000

PYPY现在跑算法的速度快接近无优化的C了，但实际时候其他的开销还是很大。

楼主你觉得计算机的妹子能保持单身的一起工作有啥激励作用，不单身的也只能YY一下而已（能YY的已经不错了）

跟“哦”一样的平常回复语，只不过是没其他话说才会用，你想多了

通过memcached协议访问innodb内容，需要改变现有项目中通过sql查询的方式。复杂查询也很难迁移。

https协议，java客户端都是直接看通讯协议的节奏。
再防也顶多像腾讯一样搞得cracker烦到家，还是能搞出东西来。

直接封盗用ip和找律师吧

my.cnf里还有其他memory设置吧，加在一起不要超过内存总量80%