推荐学习书目
› Python Cookbook
› Using Google App Engine
推荐下载
› Latest Google App Engine SDK
其他兼容技术
› AppScale
This topic created in 5642 days ago, the information mentioned may be changed or developed.
 |
haohaoleeMay 27, 2011
1
没有http长连接？
|
 |
nttdocomoMay 30, 2011
2
channel不是用来实现长连接的吗？
|
 |
szqtMay 30, 2011
3
会被gfw关照
|
 |
fengluoMay 30, 2011
4
墙！
|
 |
xreaMay 30, 2011
5
Qiang !
|
 |
6
讨论下纯粹的技术有那么难么？
我们都知道中国政府部署了一些技术挡掉了 *.appspot.com，但是这个和 GAE 平台的技术发展其实没有任何关系。我们讨论点技术吧。 |
 |
dongshengMay 30, 2011
9
撇开墙的因素，即使在国外gae也不是个流行的解决方案。
其实我感觉gae对中小企业绝对是个福音，基本上只要投资个域名就完成了建站过程。gae没有理想中发展起来，我认为更多是云计算没有得到更广泛的接受，it公司从利润方面考虑也不会推荐客户去选择gae。 技术方面 1. 不方便操作文件，比如设计一套支持模版的系统，怎么让用户自定义的模版传上去就是个问题，我不觉得把文件存在data source里是个好的办法，google storage发布了，可能能缓解这个问题吧，但这始终不如操作本地文件方便快捷。 2. 不支持大众化的开发语言，刚开始支持python，后来多了java，现在又多了个go，这都不如直接加入php影响大，google的架构似乎不太可能会加入php |
 |
ccdjhMay 30, 2011
10
本地导入1万条以上数据后，整个GAE的demo会变的很占资源。
|
 |
leptureMay 30, 2011
11
Datastore 本身的效率问题。 filter IN sucks ， 效率极差，还不如循环query，然后在程序里重组query结果。
其它的都还不错。 |
 |
lenmoreMay 31, 2011
12
如楼上所说，Datastore做的太烂了。
|
 |
istefMay 31, 2011
13
没有文件读写。。。
|
 |
jckweiJun 1, 2011
14
太好了，至少个人觉得对大多数应用足够。有时候不是平台局限，而是思维局限，用它做它能做的事。
|
 |
SjmrJun 8, 2011
16
我很希望它对 XMPP 的支持能够更全面点，比如能把 Google Apps 的域名用作 JID，自定义头像，默认状态等等，而不是使用它的域名，同样的还有 mail 也是，收件账号和发件账号希望可以自定义。
|
 |
iandyhJun 8, 2011
17
高效率的分页很痛苦。
One-to-Many relationship 需要仔细设计。 |
 |
ayanamistJun 8, 2011
19
为什么没人提完全不可靠的数据读写，以及任何操作？
写入数据很可能timeout，读取也是。就连query方法获取当前位置也会timeout xmpp发消息探测状态会莫名奇妙的xmpp.Error 还有完全没有文档介绍的各种ApplicationError，以及urlfetch不抛出timeout，直接全局DeadlineExceed了 另外各种每秒5次的操作限制（读取写入Datastore，urlfetch等等），就连taskqueue也会因为莫名的timeout而存储失败，也做不了跨请求的调度这些很容易超标的api。 总之非常的不稳定，不是花钱能解决问题的。 |
|
iandyhJun 8, 2011
20
@lepture 做社区类型的，还是需要吧。尤其是一个贴有很多回复的，过了 1000 个，用 range 这个方法就不行了，除非用每一个回复的 id 做 primary key。
嗯，全文搜索，赞同。我也在为这个伤脑筋。。 |
|
iandyhJun 8, 2011
21
@ayanamist 大量的写入可以用 Task Queue 来做。如果是 back-end 需求，现在也有新的服务提供了。 我觉得 Google 提供的 Transaction 已经很棒，ACID 都满足了。对于一个分布式的架构，能做到这点很牛逼。
你真的有 entity 达到每次 5 秒的写入频率？如果你的 app 一天使用 10 个小时，那也是而是万 PV 每天啊。即便有，Google 也有提供文档告之如何避免 Data contention 吧。 |
|
ayanamistJun 8, 2011
22
@iandyh 我是做GTalk机器人的，瞬发能达到每秒5次甚至更多。你真的应用过Task Queue吗？由于基于Datastore，所以一样会出现Timeout导致Task存储失败。Google的那个文档是扯淡的，潜在的鼓励你花钱去买他的服务。我已经用了一些很dirty的hack了。
Transaction也不靠谱的，在高写入情况下一样会有各种问题。我后台那里长长的各种诡异的Error就不截图了。你可以去看看我写的TwiTalkerPlus的代码，很多恶心的实现都是被逼的 |
|
iandyhJun 8, 2011
24
@ayanamist 我现在在用 Task Queue，做后台计算。
本身 Transaction 就无法应对高写入啊，你的例子需要用到 http://code.google.com/appengine/articles/scaling/contention.html 这篇文章用到的东西。 |
 |
tiooverJun 8, 2011
25
django版本太低了都懒得修改
|
 |
fzcsJun 9, 2011
28
DataStore 的查询性能
|
 |
fanzeyiJun 9, 2011
29
SDK不支持python2.7....
Fedora 15都换到 Python3.*了... 本来SDK在2.7都基本没法用... 到3.*根本没法想... 愁.. |
 |
kojpJun 9, 2011
30
数据备份，导入导出！！！！！！！！！！！！！
我现在还不知道怎么备份～～～没有相应的好用的工具，自己写不来！！！ |
 |
iwinuxJun 9, 2011
31
|
|
ayanamistJun 9, 2011
32
@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我就不说了。 |
 |
phusJun 9, 2011
33
@ayanamist gzip的补丁我的理解是这样的，作用是goagent的local proxy在收到text/*这种数据的时候，先用gzip压一下再传给浏览器。如果理解无误的话，我的想法是，goagent是本机127.0.0.1回环端口监听的话，压缩和不压缩区别不大，可能会更耗时一点。
这个补丁在goagent作为局域网代理的好处和优势是非常明显的。但这个场景goagent不是很关注，因为goagent作为一个简陋的本机代理(比TwiTalkerPlus简陋很多)，作为局域网代理实在不太胜任啊～～ |
 |
yyfearthJun 11, 2011
37
gae还是没有ec2好使
|
Select Language