推荐学习书目
› Python Cookbook
› Using Google App Engine
推荐下载
› Latest Google App Engine SDK
其他兼容技术
› AppScale
这是一个创建于 4923 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了这个帖子http://v2ex.appspot.com/t/13587 大概还没多少人意识到GAE是个多么烂的平台，除了免费一无是处。稳定性可以认为是没有的
你们有几个人能看出这个错误究竟出在哪里？TwiTalkerPlus源代码是开放的，你们可以去看看web.py这个文件里究竟是什么代码可能引起这个问题。
你们有几个人能看出这个错误究竟出在哪里？TwiTalkerPlus源代码是开放的，你们可以去看看web.py这个文件里究竟是什么代码可能引起这个问题。
 |
1
real_newbie 2011-06-09 13:27:46 +08:00
v2ex不是還挺穩定的嘛.
|
 |
2
ayanamist OP @real_newbie @Livid 肯定加了不少hack的
|
 |
3
kongruxi 2011-06-09 13:48:38 +08:00
python不懂，所以帮不了你
不过曾经在微博上看过一句话：那些看起来非常复杂非常不可思议的bug，最终的原因总是因为写代码的时候自己是个傻瓜！ |
 |
4
linsk 2011-06-09 13:49:21 +08:00
web.py只是框架之一，即使web.py真的糟糕，也不能断定一个平台糟糕，平台看重的是稳定性和安全性吧
|
|
5
ayanamist OP @linsk 拜托，只是刚好我的文件名叫web.py，和那个框架半毛钱关系没有
@kongruxi 麻烦你先去看看我的源代码和截图吧。 楼上两位不看截图不看源代码，就凭着我正文里的话就开始瞎发言，真是服了 |
|
6
ayanamist OP 刚把文件名改了，请看www.py这个文件，省的一些望文生义的家伙把某知名框架都圈进来
|
 |
7
jckwei 2011-06-09 14:45:39 +08:00
我一直用，接近两年了，觉得挺好，也做了一个类似v2ex的应用 http://www.xibu.biz/ 在相同的资源下承载比v2ex 好，用的是@keakon开发的YUI 框架，后来发现，即使是使用GAE自带的webapp框架也能更好、更简单、更高效实现，因为YUI主要是keakon个人针对自己需要开发的，好多功能我没有用到。
正如web.py或庞大的django（相对GAE下框架来说），他们可以让你使用简单的代码就可以实现很多通用功能，但单独一个应用往往只需要某些少量的功能。 |
|
10
ayanamist OP @jckwei 我懒得专门bundle一个模板引擎不好么。本来就是简简单单的做个web页面。我这个应用web页面又不是重点。
|
 |
11
zhuang 2011-06-09 14:59:03 +08:00
gae 对资源的限制比较厉害，毕竟人家是免费的么……
DeadlineExceed 就是告诉你，该付费了啊～ 你倒是可以问问Livid 具体付费的服务怎么样，你拿别人给的免费资源玩玩也就算了，想真用到生产环境里，还不愿意投资，不能因为这就说人家稳定性不好吧。 gae 的datastore 部分太麻烦，我也不用，但是我觉得从v2ex 来看，付费的服务是相当有保障的，而且是稳定且经济的。 |
|
14
zhuang 2011-06-09 15:51:05 +08:00
@ayanamist
我了解不多，我个人理解DeadlineExceedError 的优先级明显是高于ApplicationError 的，比如说一个url fetch，它很可能应该正常返回一个timeout，但是这时候DeadlineExceedError 被触发了……那很悲剧，你根本无从得知背后发生了什么。我想这是你要抱怨的东西。 换作你来提供一个横跨免费到企业服务的业务，你会怎么设计quota 相关的逻辑？你会不会在超出使用范围之后一刀切？理解一下吧，其实你有除了抱怨之外的选择。 |
 |
15
chone 2011-06-09 16:23:39 +08:00
想让马儿跑，又不想让马儿吃草。。。
|
 |
17
panlilu 2011-06-09 16:58:48 +08:00
TwiTalker一直在用，TwiTalkerPlus有什么特别的地方么？
|
|
18
ayanamist OP |
|
19
ayanamist OP @panlilu 功能更全面，不过我修改的频繁，也较不稳定一些。支持短ID，对Twitter的功能支持的更全面一些。
|
 |
20
raptium 2011-06-09 17:36:01 +08:00
ms=73738 cpu_ms=90 api_cpu_ms=0 怎么觉得看起来像是迅雷下得太欢导致不够带宽访问啊= =
|
|
21
ayanamist OP @raptium 你牛逼啊，GAE那端报错，和我迅雷有什么关系！我还没满速呢！我这里可以4M/s的好不好，浏览网页都无比正常
|
|
22
real_newbie 2011-06-09 17:56:44 +08:00
|
|
23
zhuang 2011-06-09 18:38:03 +08:00
@ayanamist
不要太较真啊，这里唯一郁闷的只有你一个人，其他人想帮你，你却要传染自己的情绪给别人。 按照你自己的经验，99%正常，这是4sigma 的标准了，一个免费的服务，还不是很核心的产品，做到4sigma 的真的不多。你没有理解我的意思，或者我表达不到位，我其实是想说，作为程序作者，Robust 是要靠你自己来保证的，甚至是服务器本身也不能认为是100%可靠的。 我简单说下我参与的一个分布计算系统的设计，多层次可退化的设计，后层为前一层的逻辑缓存，每层之间定期同步校验。我们在保证数据安全的前提下，扩容变得不是那么容易。因此我们把硬件资源划分为核心区，交换区以及扩展区。新硬件资源加入的时候同步过程需要花费一定时间，前级请求虽然会缓存，但是因为网络交换延迟，以及同步运算时间，这个时间差上造成的De-sync 我们是没有能力保证其绝对正确的。所以目前的解决方案就是直接返回异常，对于客户端程序增加的成本就是异常中断的恢复处理，至于二次请求会不会造成错误，这是程序员要解决的问题。 我这里的异常可以类比到GAE 的DeadlineExceeded 错误，技术上，追踪同步期内的de-sync 是很消耗资源的事情，需要在大量节点之间反复进行验算。相比之下，返回一个代表“服务器不保证上一次请求正确”的信息可能是更高效更具成本的做法。按照我了解的数据来说，大概千分之一的时段上会出现一个unstable 的高峰，平均有0.5% 的通信会返回Unreliable 的结果。 我之前说我不了解，确实是我不了解GAE 开发，但是它的构架我之前是研究过许久的。我搜索了一下，发现普遍反映是DeadlineExceeded 和我了解的Unreliable 解决方案的状况是一样的。 我还是那句话，理解一下吧，GAE 做到现在的样子已经是相当厉害的了，与其在这抱怨你遇到的“不稳定”，不如花时间去找解决方案。 |
|
24
ayanamist OP @zhuang 谢谢你的教导。解决方案我有，虽然很dirty。我的主要观点是：虽然数据库什么无法做到可靠，但提供的API至少要做到吧。Timeout了，客户必然要retry，这个放到提供的api的框架里，免得客户为了实现可靠的数据获取，而重实现这一块吧。给出的异常也尽量准确吧。隐藏了一个ApplicationError这么大的异常，文档中却只字不提，这是什么态度。
|
 |
25
keakon 2011-06-09 19:25:44 +08:00
这个错误估计是初始化Python实例的时候超时了，所以没有异常堆栈。这种问题常见于使用Java和Django的应用，因为它们启动确实很慢。不过你这个很奇怪，一般30秒就超时退出了，你的用了70多秒，估计是系统出错了。
这种错误是随机出现的，无法避免，要知道买个VPS还可能死机呢，所以重点是错误率是多少。 在我的应用上，至少最近半年没有遇到这种问题，说明概率是小于几十万分之1的，何以得出“稳定性可以认为是没有的”？ |
 |
26
fcicq 2011-06-09 20:22:55 +08:00
偶的 GAE sites 每日有 ~100k dynamic req, 说说这个问题.
deadline error 而没有用很多 cpu 的情况下必然是 api 的超时. 用 async 的 api 会让情况好很多(timeout 明显更短). 或者也可用 taskqueue, 把耗时的, 可能会阻塞的, 可以延迟的调用放到后台去. 偶的 db req 也经常会见到有超过 30s 超时强制退出的, 但因为这些请求对服务没有致命影响, 偶认为是可以忽略的. |
 |
27
saga 2011-06-10 08:31:50 +08:00 via Android
标题党加负面思想加夸大其词 这帖子基本是没意义
|
 |
28
wangnaide 2011-07-03 11:44:13 +08:00
GAE本身还是很稳定的，但是反向代理不是那么稳定。
|
Select Language