除非你自己处理全局锁（跨各个进程、线程）的，不然就不应该把原子操作放在程序中处理；这个太复杂了。

放在数据库中操作，让它们自己处理吧。

> 那就是不需要关心负载均衡和DB压力？

这是一种误解。
@Livid 所言是指DB运行的参数，并非DB在`不正确`使用时候产生的压力。

负载均衡AWS有自己的一套解决方案，呃， 不过就这几台服务器，自己用DNS进行均衡下就可以了，还不用太高阶的，如果不是特殊要求的话。

AWS(几乎)是市面上最贵也是最稳定的，比如它能帮你抗DDOS而且不会产生费用，但似乎有人被CC攻击，然后，倒产生了一个巨大的流量账单……

如果对性能进行评测的话，AWS跟独立服务器相比，贵得离谱。

百万级的数据量不算大的，一般情况下做`正确`的索引就不会有什么问题。另外，做些监控就可以了，比如Mongodb的MMS，MySQL的国内好像有家也在做。

如果服务器是分开来的话，注意数据库的读写一致。

海外的服务器，因为不可能人跑过去，考虑到各种万一情况，不要在一个机房里集中放机器。举个例子，你的一个副本集有5个节点，其中3个A机房，另外2个B机房；如果A机房断网，像Mongodb的集群机制，就会让整个副本集挂起……

Anyway，这些渠道本身不是大问题. 除去性能不好外，最稳定的还是AWS。不过，呃，多花点钱，性能也就好了……

其实，我觉得你`流量到千万，一些大表数据量达到百万`, 没有复杂的数据挖掘的话，不考虑热备与冗余，真的是一台100美金内的独服就能完全撑住的……

@andybest 我们就是这样处理的，Base64是会导致获取的数据比源binary要大，但是一般情况下，没有3倍这么夸张。你自己弄一张图片对比一下就明白了。

是每次存取都新建了一个连接还是使用连接池的？如果是前者，每次新建TCP连接是有系统开销的。

另外，cPickle、unicode、zip、base64等，这些编码解码的效率是很高的，不会是瓶颈的。我自己用了多年的Mac上，一秒钟都能处理过亿的字节...

一般的海外线路，要先考虑去掉第一次的DNS时间，加上每次请求的TCP连接时间（接近ping值），这个估摸有500ms去掉了。

然后才是服务器处理的时间，静态的页面一般在10ms左右就会处理完，动态页面优化得好的在50~100ms左右，但多数人写程序的时候，估计都是超200ms的。
这里就静态页面完胜了。

但动态页面，都可以用内存缓存，呃，如果不要脸一点，可以手动锁定某个时间段缓存，这个性能就接近甚至超过静态页面。呃，这个真的属于“不要脸”级别的，因为完全牺牲了动态页面的特性，而且跟静态页面的逻辑从根本上来说都是一样的，没有可比性。

不过，所有的动态页面，在一个特定时间内，都是静态的。所以牺牲一点动态性，设定一个特定时间内（比如10分钟）更新缓存，这个性能则也是杠杠的；但是考虑到对内存的需求增大，如果要对文本压缩（降低对内存的需求），性能少有一些耗损，而且也不算很动态，跟静态的相比，呃，彼此伯仲吧。

但这些都弱爆了！
有没有使用过局部缓存？这个高度定制的技艺，既可以保留动态页面的实时动态，性能也非常接近静态页面！


然后，如果不考虑任何缓存，不消说，Wordpress跟Jekyll没法比，一点办法都没有。


实际上，则不用太关心选型，哪个工具符合自己的品味就好了。比如@chairuosen 同学的这个网站，从数值上来说, 应该可以用慢来形容；但实际使用过程中，是会觉得很快的，因为，从DNS开始，到页面的数据包接收回来，时间在1秒内的，都是人类认知范围内的“网速很快”……

@daodao 看你这个结果，应该是@mutoulbj 说的原因。你本地的python跟python2.7应该不是同一个东西。 MacOS是这样，最开始环境配置的时候，是比较容易遇到问题的。

我最开始的时候，对Django已经非常熟悉了；后来跟朋友做一个项目的时候，开始用Flask，然后就毅然放弃了Django了，这前估计用了四五年有吧。

Django的文档比较详尽，用的人也多一些，所以遇到再低级的问题，Google下通常都是有答案的；但到后来，Debug时会去看源码时，这就奔溃了，集成过强，关联过多，自定制很麻烦且过于复杂。

怎么选择其实都OK的。

但是！如果GC你是打算做移动端的应用，后端主要是负责数据处理的，呃，那就别从Django入门了！

@mutoulbj 呃，如果是系统升级了，注意下python自己的环境是否正常

import sys
print sys.path

# 这些路径，就是import默认会去遍历的目录； MacOS对这个处理跟其它的Linux比，是有些差异的。如果是系统版本升级了，照往年的经验，是可能出一些莫名其妙的问题的(比如不同的系统版本默认对应的python版本是不一定一样的，不一样的python版本对应的python环境也是不一定一样的。)。 10.9我没有升，所以并不清楚……

恭喜GC同学也走上了这条道路。

import django.db 这个应该是无法执行的，需要这个先执行才会生效， os.environ.setdefault("DJANGO_SETTINGS_MODULE", "djangoproject.settings")

但貌似也不应该程序退出，最多是import错误而已……

在python里直接import django是否可以？

或者直接命令行看看django是否可以import
python -c 'import django'
python -c 'import django.core'
python -c 'import django.core.management'
是否都不会抛错？


有没有可能你自己的文件夹/Users/daodao/Desktop/djangoproject/中有个子文件夹叫django?

另外django这个包的安装，本身没有太大的依赖性，只要确认/Library/Python/2.7/site-packages/下有django的文件夹，基本都是成功安装了的。

或者执行下面这行命令。

ls /Library/Python/2.7/site-packages/ | grep 'django'


- - - - - - - -

归根结底，这个问题可能跟django本身没有多大的关系，是import失败。关于python的import逻辑，可能需要自己再去了解下。

另外，不知道现在用的django是什么版本的（跟教程的是否是一致的），我印象中早先以前的一个django版本中默认创建出来的manage.py的处理逻辑稍微有点不一样了。 呃，这个原因的概率应该不大。


对了，入门上手Django，我个人持保留态度。有时间可以试试了解下Flask或web.py，如果感觉更容易接受，就选后者；如果不行，就选Django。再有就是试试用PyCharm作为自己的IDE，等有一天，可以自由地在各个源码间穿梭，就感觉良好了。

呃，@shiny 同学，你可以考虑请我吃饭了。

用日期作为key，也未必是坏事。比如用作统计的，而且年/月/日这些固定的（非range性质)的，可以用正则的前向匹配，同时，也是可以使用索引的。所以，这反而是一个高效的处理办法。

但有一个问题，比如`2012-09`这样的key来存储一个月的数据（按天），那么，（有人）推荐的做法，是创建这个document的时候，就填充好31天的空数据。

呃，为什么是`2012-09`而不是`2012-9`呢？ 这跟`2012-10`对比，会产生大小的问题，也可以很漂亮地解决时间被str化后的排序问题。

- - - - -

所有的字段如何控制，都是个人的一种选择。但是内嵌字段中出现一些特殊值，比如`$`开头的, 带`.`的，则要对MongoDB要更了解一些，不然很容易入坑。

- - - -

用内嵌文档，不会产生性能的问题。

用内嵌文档，并且不断insert，这会是性能问题产生的原因。

MongoDB是文档型的数据库，一个文档被创建的时候，默认会有保留多一点的空区域（这种机制，也会MongoDB等NoSQL数据库比较占磁盘空间的原因），可以方便以后的更新操作。但是，这个区域占满之后，磁盘空间就需要重新分派（这是极低效的）。

如果这是过程中，有多一点量的写操作涌进来，呃，肯定会“卡得掉眼泪”了。

JSON是JSON， MongoDB是MongoDB。

不论是扁平还是多层内嵌，是个人的选择问题；但只有一个前提，就是不能影响数据库的性能。

扁平相对而言是会简单一些，内嵌的，具体场景中，性能反倒会更高。

因为在MongoDB的底层存储中，对内嵌文档的处理并非是大家想象中的那般结构化，但比如要更新`collection.field1.field2.field3.field5`这到底更新了哪段信息？如果我有个字段名就是`field1.field2`的联合呢？

@shiny 内嵌文档的大小也在频繁变化么？

一般情况下，性能差距不大。直接遍历find获得cursor，实际上（pymongo）会获取一些数据，等这些数据不够用了，然后再去获取。跟limit产生的信息流实际上是一样的。

归根结底是在于应用场景的索引是如何建的？如果数据都属于热数据，find or limit，没有什么差别，基本上可以认为是从内存中取的。

但不管怎么样，这种场景下，不建议直接用find这个cursor，设一个最大的limit值也好（一般情况下）。如果你自己不小心手滑，没有终止迭代，并且collection的数据量很大……

@clker 推荐使用pycharm作为开发工具。剩下的就靠自己吧，可能会艰难一点，但自通了，进步就是极快的。

@Muninn 你没有明白我的意思。

1， 如果是整个程序挂掉了，logging最后是默认在工作的，也就是一般情况下，你自己运行一个py文件，然后报错的输出。这个原理跟重写一个sys.excepthook是一样的。

2，如果是以daemon运行，那么你需要的是让err logging最终保留到一个日志中。也就是你要把stderr从屏幕打印转为文件保存。建议试试supervisor，里面有redirect_stderr与stdout_logfile可以进行配置。

3，如果只是想极简单的处理这个问题，自己写个函数，处理错误的信息（即保存到某个文本中），赋值给sys.excepthook就可以了。


- - - -

“我感觉程序崩溃了直接根据异常查错误就完了,捕获了再退出岂不是多此一举?”

触发的错误，即使是同一种错误，但是触发点（运行时的错误点）在不同文件中，那么收集到的错误信息也是不一样的，包括所在代码行，当前运行的上下文环境等。你可能会遇到很多基本就无法重现的问题，（多数是Web环境，或者其它非独自使用的程序）。呃，因为，我感觉可能是自己水平所限，无法解释清楚了。所以，我说，你再想想？

@xiaket 嗯，如果这样的话，那是我的错。 :) @clker 那你应该看一下自己的数据库中，是否数据都进去了，另外，在程序执行的时候，打上断点，就清楚其执行逻辑了。

建议使用@Livid 推荐的sentry，它源码是开放的，自己的github上下过来搭一个，会方便很多。

另外，不推荐“尽你所能去捕获异常”，异常的捕获可以作为基础逻辑进行判断，这确实是Python的一个特性；但是捕获所有的异常，这不现实。

如果所有异常需要输出，比较快的方法是写个函数（来处理/打印异常信息），最后将函数赋值给sys.excepthook上就可以了。

“我感觉程序崩溃了直接根据异常查错误就完了,捕获了再退出岂不是多此一举?” --> 关于这个问题，你自己再想想？

建议1，不要堆积垃圾代码
username = request.POST.get('username', '').strip()
这行代码能代替你原来的5行代码，如果你需要取的变量很多，那么，这样的代码也会成为垃圾代码，需要自己另写一个常用的以应对

建议2，有意义比简短更重要
pwd_blank 不如 pwd_is_blank, pwd_is_blank = 1 不如 pwd_is_blank = True

建议3, 既然用了Django，就应该了解它最基础的逻辑
我如果记得没错的话，User.objects.filter(username = username)这样返回的一个QuerySet对象，如果用if去判断，那么永远都相当于 True，应该是User.objects.filter(username = username).count(), 是这样么？

建议4, 不要妄下判断，以目前的水平，多数的问题是出在自己的身上
“先if 和 else 均被执行，而且还是先执行else” --> 这样的结论如果成立，你可以给python的核心库打补丁了。

建议5, 不要说本地没问题，不要把问题强加给不相关的方面
呃，你看下自己的数据库，里面的数据可能跟自己想的也不一样。归根结底是表面的逻辑出问题了。对，这个跟SAE也无关。

建议6，还没有学会如何DEBUG吧？

@sdjl __getitem__ 和 next 两个函数在pymongo中是应对不通场景的调用，所以都有，只去掉其中一个，呃，这仍然是可遍历的。

还是建议自己打patch，调用比较方便，也可以不用管后面的实现。之前有个版本，作者对__getitem__函数的处理就不一样，测试没有跑全就发布了，然后就bug了。