能赚钱就行

@est 但是至少 tornado 还能快速响应其他请求（非数据库相关请求），如果业务上没需求的话，这个也然并卵

@hyy 创建快的话，也不会耽误多少服务器启动时间; 创建慢的话，到用的时候不就响应慢了。所以无论快慢在服务器起来的时候就创建啊。数据库对象池创建很慢吗？！

我觉得最近几年的 thinkpad 的键盘越做越松散， touch pad 简直不能用，小红点用不惯，再配上大色块的 win8,简直了～～～， 唉，以前对 thinkpad 感觉蛮好的，都是被 mbp 害的。

我歪楼了吗？

delayrun 每次跑起定时器后就退出去了，没有嵌套

@SoloCompany 呵呵，之前脑子抽住了，错误地认为 login form 传的是散列后的密码，其实密码散列计算在 server 端做的，那么 basic auth 也是 ok 的。

sorry, 理解错了。 base64 解码后和标准认证是一样的

@cyberdak
@tony1016
basic authentication, 就是对原始密码进行 base64 编码，如果系统只保存散列密码， basic auth 怎么认证呢？
所以为了支持 basic auth, 它要么保存原始密码，要么对原始密码进行对称式加密保存。

@msg7086 1TB 能到的话， 10TB 也能到，体积差不太多，带宽*10 了。怎么有种跟在出租车后面跑比公交车省钱的味道~~~

光纤和你的 IP 在 NAT 后没有关系啊， NAT 穿透当然有用啊。貌似没啥新技术

把耗时操作交给后台，不阻塞 ternado 的 loop 。 try celery

@raiz 这要看具体应用啊，比如图片，要显示总是需要全部的数据。比如音频视频，文件很大，播放是流的方式，只需要分片取，不需要全部数据都进 memory

class io.BytesIO([initial_bytes])
A stream implementation using an in-memory bytes buffer.

raw_file 是文件流，如果 open 时如果是 rb 的， buffering=-1 的，则使用内置的 chunked buffer ，这是针对你参数的结果。

从 file.read(1)上看，都是从 file 流里取 1 个字节。从效率上看， BytesIO 是内存访问， raw_file 是 buffer+Filesystem io 的结果，所以貌似慢一点。

但这都不是正确的打开方式，要效率高就要 chunk 读，减少 FS IO 和循环次数。 BytesIO 更大的意义在抽象层次上， fs 和 buffer 都能通过 file io 访问，是不是 test 的时候简单一点？

如果错误请指正，欢迎探讨。 -)

通信协议不是项目负责人定的吗？再不济，前后端和负责人一起讨论。哪有开发过程中前后端通信约束都没有，后端应该给什么，前端要什么都不定，那还做什么项目？！前后端负责人都炒掉算了。

主题就是粗体字，楼主真能写！

轻耦合，高内聚。
往这 2 个靠准没错

《禁室培欲》宿舍版

第一句话是对的，后面的话无法验证第一句