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

v2ex不是挺定的嘛.

@real_newbie @Livid 肯定加了不少hack的

python不懂，所以帮不了你

不过曾经在微博上看过一句话：那些看起来非常复杂非常不可思议的bug，最终的原因总是因为写代码的时候自己是个傻瓜！

web.py只是框架之一，即使web.py真的糟糕，也不能断定一个平台糟糕，平台看重的是稳定性和安全性吧

@linsk 拜托，只是刚好我的文件名叫web.py，和那个框架半毛钱关系没有
@kongruxi 麻烦你先去看看我的源代码和截图吧。

楼上两位不看截图不看源代码，就凭着我正文里的话就开始瞎发言，真是服了

刚把文件名改了，请看www.py这个文件，省的一些望文生义的家伙把某知名框架都圈进来

我一直用，接近两年了，觉得挺好，也做了一个类似v2ex的应用 http://www.xibu.biz/ 在相同的资源下承载比v2ex 好，用的是@keakon开发的YUI 框架，后来发现，即使是使用GAE自带的webapp框架也能更好、更简单、更高效实现，因为YUI主要是keakon个人针对自己需要开发的，好多功能我没有用到。

正如web.py或庞大的django（相对GAE下框架来说），他们可以让你使用简单的代码就可以实现很多通用功能，但单独一个应用往往只需要某些少量的功能。

@jckwei 同学，我对你自顾自说话的精神表示泪流满面，我连文件名都为你改了啊……

@ayanamist 不好意思，

但看了www.py 还是引用的django这个庞然大巫

@jckwei 我懒得专门bundle一个模板引擎不好么。本来就是简简单单的做个web页面。我这个应用web页面又不是重点。

gae 对资源的限制比较厉害，毕竟人家是免费的么……
DeadlineExceed 就是告诉你，该付费了啊～
你倒是可以问问Livid 具体付费的服务怎么样，你拿别人给的免费资源玩玩也就算了，想真用到生产环境里，还不愿意投资，不能因为这就说人家稳定性不好吧。
gae 的datastore 部分太麻烦，我也不用，但是我觉得从v2ex 来看，付费的服务是相当有保障的，而且是稳定且经济的。

@zhuang 问题是我已经展开了，而且没有什么代码屏蔽错误的，他什么代码异常都没有就直接超时了？

@ayanamist 换个角度：如果用其它框架实现通过gtalk或QQ、MSN发Tw看看。

感觉可能更好。

@ayanamist
我了解不多，我个人理解DeadlineExceedError 的优先级明显是高于ApplicationError 的，比如说一个url fetch，它很可能应该正常返回一个timeout，但是这时候DeadlineExceedError 被触发了……那很悲剧，你根本无从得知背后发生了什么。我想这是你要抱怨的东西。
换作你来提供一个横跨免费到企业服务的业务，你会怎么设计quota 相关的逻辑？你会不会在超出使用范围之后一刀切？理解一下吧，其实你有除了抱怨之外的选择。

想让马儿跑，又不想让马儿吃草。。。

@ayanamist 那个 DeadlineExceedError 是在什么情况下抛出来的？截图里没有截到你的代码文件名……

TwiTalker一直在用，TwiTalkerPlus有什么特别的地方么？

@iwinux 请注意已经是减号状态了，已经展开了，所以我才截图。我也不知道是哪里出了问题
@chone 吃草就吃草，不要往外弄些别的东西。我出的这个问题和付费不付费无关吧
@zhuang 同学，我不想再贴一张其它的引发DeadlineExceedError的截图了，其它的99%的都会有traceback。麻烦你没开发过GAE平台就不要猜想什么的

@panlilu 功能更全面，不过我修改的频繁，也较不稳定一些。支持短ID，对Twitter的功能支持的更全面一些。

ms=73738 cpu_ms=90 api_cpu_ms=0 怎么觉得看起来像是迅雷下得太欢导致不够带宽访问啊= =

@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本身还是很稳定的，但是反向代理不是那么稳定。