1
haohaolee 2011-05-27 00:40:32 +08:00
没有http长连接?
|
2
nttdocomo 2011-05-30 09:04:47 +08:00
channel不是用来实现长连接的吗?
|
3
szqt 2011-05-30 09:15:36 +08:00
会被gfw关照
|
4
fengluo 2011-05-30 09:24:35 +08:00
墙!
|
5
xrea 2011-05-30 10:03:38 +08:00
Qiang !
|
6
Livid MOD 讨论下纯粹的技术有那么难么?
我们都知道中国政府部署了一些技术挡掉了 *.appspot.com,但是这个和 GAE 平台的技术发展其实没有任何关系。我们讨论点技术吧。 |
9
dongsheng 2011-05-30 10:14:21 +08:00
撇开墙的因素,即使在国外gae也不是个流行的解决方案。
其实我感觉gae对中小企业绝对是个福音,基本上只要投资个域名就完成了建站过程。gae没有理想中发展起来,我认为更多是云计算没有得到更广泛的接受,it公司从利润方面考虑也不会推荐客户去选择gae。 技术方面 1. 不方便操作文件,比如设计一套支持模版的系统,怎么让用户自定义的模版传上去就是个问题,我不觉得把文件存在data source里是个好的办法,google storage发布了,可能能缓解这个问题吧,但这始终不如操作本地文件方便快捷。 2. 不支持大众化的开发语言,刚开始支持python,后来多了java,现在又多了个go,这都不如直接加入php影响大,google的架构似乎不太可能会加入php |
10
ccdjh 2011-05-30 10:38:34 +08:00
本地导入1万条以上数据后,整个GAE的demo会变的很占资源。
|
11
lepture 2011-05-30 10:44:38 +08:00
Datastore 本身的效率问题。 filter IN sucks , 效率极差,还不如循环query,然后在程序里重组query结果。
其它的都还不错。 |
12
lenmore 2011-05-31 14:51:26 +08:00
如楼上所说,Datastore做的太烂了。
|
13
istef 2011-05-31 15:34:21 +08:00
没有文件读写。。。
|
14
jckwei 2011-06-01 23:14:09 +08:00
太好了,至少个人觉得对大多数应用足够。有时候不是平台局限,而是思维局限,用它做它能做的事。
|
16
Sjmr 2011-06-08 20:03:27 +08:00
我很希望它对 XMPP 的支持能够更全面点,比如能把 Google Apps 的域名用作 JID,自定义头像,默认状态等等,而不是使用它的域名,同样的还有 mail 也是,收件账号和发件账号希望可以自定义。
|
17
iandyh 2011-06-08 20:55:02 +08:00
高效率的分页很痛苦。
One-to-Many relationship 需要仔细设计。 |
19
ayanamist 2011-06-08 21:41:08 +08:00
为什么没人提完全不可靠的数据读写,以及任何操作?
写入数据很可能timeout,读取也是。就连query方法获取当前位置也会timeout xmpp发消息探测状态会莫名奇妙的xmpp.Error 还有完全没有文档介绍的各种ApplicationError,以及urlfetch不抛出timeout,直接全局DeadlineExceed了 另外各种每秒5次的操作限制(读取写入Datastore,urlfetch等等),就连taskqueue也会因为莫名的timeout而存储失败,也做不了跨请求的调度这些很容易超标的api。 总之非常的不稳定,不是花钱能解决问题的。 |
20
iandyh 2011-06-08 22:10:36 +08:00
@lepture 做社区类型的,还是需要吧。尤其是一个贴有很多回复的,过了 1000 个,用 range 这个方法就不行了,除非用每一个回复的 id 做 primary key。
嗯,全文搜索,赞同。我也在为这个伤脑筋。。 |
21
iandyh 2011-06-08 22:16:07 +08:00
@ayanamist 大量的写入可以用 Task Queue 来做。如果是 back-end 需求,现在也有新的服务提供了。 我觉得 Google 提供的 Transaction 已经很棒,ACID 都满足了。对于一个分布式的架构,能做到这点很牛逼。
你真的有 entity 达到每次 5 秒的写入频率?如果你的 app 一天使用 10 个小时,那也是而是万 PV 每天啊。即便有,Google 也有提供文档告之如何避免 Data contention 吧。 |
22
ayanamist 2011-06-08 23:22:40 +08:00
@iandyh 我是做GTalk机器人的,瞬发能达到每秒5次甚至更多。你真的应用过Task Queue吗?由于基于Datastore,所以一样会出现Timeout导致Task存储失败。Google的那个文档是扯淡的,潜在的鼓励你花钱去买他的服务。我已经用了一些很dirty的hack了。
Transaction也不靠谱的,在高写入情况下一样会有各种问题。我后台那里长长的各种诡异的Error就不截图了。你可以去看看我写的TwiTalkerPlus的代码,很多恶心的实现都是被逼的 |
24
iandyh 2011-06-08 23:52:10 +08:00
@ayanamist 我现在在用 Task Queue,做后台计算。
本身 Transaction 就无法应对高写入啊,你的例子需要用到 http://code.google.com/appengine/articles/scaling/contention.html 这篇文章用到的东西。 |
25
tioover 2011-06-08 23:57:01 +08:00
django版本太低了都懒得修改
|
26
phus 2011-06-09 09:36:41 +08:00
@ayanamist 同感同感,urlfetch的各种ApplicationError就已经很郁闷了,所以我搞goagent就没用Datastore。
|
28
fzcs 2011-06-09 09:53:20 +08:00
DataStore 的查询性能
|
29
fanzeyi 2011-06-09 09:57:44 +08:00
SDK不支持python2.7....
Fedora 15都换到 Python3.*了... 本来SDK在2.7都基本没法用... 到3.*根本没法想... 愁.. |
30
kojp 2011-06-09 10:53:12 +08:00
数据备份,导入导出!!!!!!!!!!!!!
我现在还不知道怎么备份~~~没有相应的好用的工具,自己写不来!!! |
31
iwinux 2011-06-09 11:14:57 +08:00
|
32
ayanamist 2011-06-09 11:55:32 +08:00
@iwinux 没信用卡的只能免费。你提的空间太小不算问题。这个需求只能付费,要不你就gzip一下然后消耗CPU吧。没有靠谱的图片处理确实是个大问题,也没有纯py的实现,gae的那几个太弱了,只能处理下头像都感到吃力
@fanzeyi 你这些都无所谓,生产环境里py25不算低,大部分py2的核心特性都已经支持了,DotCloud还不是py26。py27改变较大,很多模块都不能用了。另外sdk在py27可以用吧……你好像不熟悉py,py2和py3的区别都没搞明白吧 @phus 老大,你为啥不合并我的gzip?而是把那个无关紧要的异常处理给合并了…… @iandyh 用Transaction的一个好处是可以自动重试。我已经shard了,保持small entity做不到(本身已经很小了)。但就算是shard了还是不行啊。关键是应用级的shard一旦弄好,要修改就很麻烦。defer我就不说了。 |
33
phus 2011-06-09 12:16:32 +08:00
@ayanamist gzip的补丁我的理解是这样的,作用是goagent的local proxy在收到text/*这种数据的时候,先用gzip压一下再传给浏览器。如果理解无误的话,我的想法是,goagent是本机127.0.0.1回环端口监听的话,压缩和不压缩区别不大,可能会更耗时一点。
这个补丁在goagent作为局域网代理的好处和优势是非常明显的。但这个场景goagent不是很关注,因为goagent作为一个简陋的本机代理(比TwiTalkerPlus简陋很多),作为局域网代理实在不太胜任啊~~ |
37
yyfearth 2011-06-11 12:07:59 +08:00
gae还是没有ec2好使
|