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