一定要让你们知道GAE平台究竟是一个多么烂的平台

@raptium 你牛逼啊，GAE那端报错，和我迅雷有什么关系！我还没满速呢！我这里可以4M/s的好不好，浏览网页都无比正常

http://groups.google.com/group/google-appengine

也許可以去這裡問問?

@ayanamist
不要太较真啊，这里唯一郁闷的只有你一个人，其他人想帮你，你却要传染自己的情绪给别人。
按照你自己的经验，99%正常，这是4sigma 的标准了，一个免费的服务，还不是很核心的产品，做到4sigma 的真的不多。你没有理解我的意思，或者我表达不到位，我其实是想说，作为程序作者，Robust 是要靠你自己来保证的，甚至是服务器本身也不能认为是100%可靠的。

我简单说下我参与的一个分布计算系统的设计，多层次可退化的设计，后层为前一层的逻辑缓存，每层之间定期同步校验。我们在保证数据安全的前提下，扩容变得不是那么容易。因此我们把硬件资源划分为核心区，交换区以及扩展区。新硬件资源加入的时候同步过程需要花费一定时间，前级请求虽然会缓存，但是因为网络交换延迟，以及同步运算时间，这个时间差上造成的De-sync 我们是没有能力保证其绝对正确的。所以目前的解决方案就是直接返回异常，对于客户端程序增加的成本就是异常中断的恢复处理，至于二次请求会不会造成错误，这是程序员要解决的问题。
我这里的异常可以类比到GAE 的DeadlineExceeded 错误，技术上，追踪同步期内的de-sync 是很消耗资源的事情，需要在大量节点之间反复进行验算。相比之下，返回一个代表“服务器不保证上一次请求正确”的信息可能是更高效更具成本的做法。按照我了解的数据来说，大概千分之一的时段上会出现一个unstable 的高峰，平均有0.5% 的通信会返回Unreliable 的结果。

我之前说我不了解，确实是我不了解GAE 开发，但是它的构架我之前是研究过许久的。我搜索了一下，发现普遍反映是DeadlineExceeded 和我了解的Unreliable 解决方案的状况是一样的。
我还是那句话，理解一下吧，GAE 做到现在的样子已经是相当厉害的了，与其在这抱怨你遇到的“不稳定”，不如花时间去找解决方案。

@zhuang 谢谢你的教导。解决方案我有，虽然很dirty。我的主要观点是：虽然数据库什么无法做到可靠，但提供的API至少要做到吧。Timeout了，客户必然要retry，这个放到提供的api的框架里，免得客户为了实现可靠的数据获取，而重实现这一块吧。给出的异常也尽量准确吧。隐藏了一个ApplicationError这么大的异常，文档中却只字不提，这是什么态度。

这个错误估计是初始化Python实例的时候超时了，所以没有异常堆栈。这种问题常见于使用Java和Django的应用，因为它们启动确实很慢。不过你这个很奇怪，一般30秒就超时退出了，你的用了70多秒，估计是系统出错了。

这种错误是随机出现的，无法避免，要知道买个VPS还可能死机呢，所以重点是错误率是多少。

在我的应用上，至少最近半年没有遇到这种问题，说明概率是小于几十万分之1的，何以得出“稳定性可以认为是没有的”？

偶的 GAE sites 每日有 ~100k dynamic req, 说说这个问题.
deadline error 而没有用很多 cpu 的情况下必然是 api 的超时. 用 async 的 api 会让情况好很多(timeout 明显更短).
或者也可用 taskqueue, 把耗时的, 可能会阻塞的, 可以延迟的调用放到后台去.

偶的 db req 也经常会见到有超过 30s 超时强制退出的, 但因为这些请求对服务没有致命影响, 偶认为是可以忽略的.

标题党加负面思想加夸大其词 这帖子基本是没意义

GAE本身还是很稳定的，但是反向代理不是那么稳定。