V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  keakon  ›  全部回复第 37 页 / 共 53 页
回复总数  1042
1 ... 33  34  35  36  37  38  39  40  41  42 ... 53  
2011-09-07 13:34:02 +08:00
回复了 jeeson 创建的主题 Google App Engine GAE 新定价下, instance hours 没那么可怕
@sohoer 更新量不大,小的更新我都不会去删除缓存。

顺便更正上面一个错误,PV数应该翻倍,因为memcache有55%的命中率。

再给个数据吧,我每天的请求数是2万多,Datastore Reads是7万多。这几天优化过后变成5万了,昨晚又优化了一个地方,但估计只能降到4万,几乎没多少增长空间了。
2万/天请求换算成秒只相当于0.2 QPS,而实际上平均0.1秒就能处理一个请求。也就是说,免费配额虽然给了一个免费的instance,但80%的时间都必须让它空闲着。
2011-09-07 12:28:53 +08:00
回复了 jeeson 创建的主题 Google App Engine GAE 新定价下, instance hours 没那么可怕
@jeeson @lfeng 我觉得你们还是看看Billing History里的Datastore Reads再辩驳吧。

前面我已经说过了,我几乎对所有的数据库访问都做了缓存,这点你可以在我博客的源码里看到,有遗漏的你可以指出。

昨晚我对所有的数据库访问都进行了记录,并将获取超过5个实体的请求用warning标记出来。在后台可以看到最近5分22秒内有20个这样的请求,共计178个实体。其中所有请求的URL都不相同,获取的数据也都不相同,并且我都做过缓存但没有命中。这都是由访问者决定的,我不可能只让他们访问已经缓存的页面。

虽然1个PV可能会有1~3个动态请求,不过我就按1个来算,最多也只有20PV,因此理论上来说5万/天的配额只能支持到5600PV。考虑到少于5个实体的请求我没记录,实际情况只会更少。
至于最开始时,Google承诺的是免费配额可以支持每月500万PV,相差将近30倍。

顺便提醒一下,count操作虽然只返回一个整数,但也算多次key fetch。所以如果你的实体超过50000,然后执行count(50000),你会发现Small Datastore Operations配额已经用完了,而这花不了几秒…
2011-09-07 09:59:35 +08:00
回复了 jeeson 创建的主题 Google App Engine GAE 新定价下, instance hours 没那么可怕
@jeeson @lfeng 高不了的…我几乎对所有的数据库访问加了缓存,目前的状态是Hit ratio: 55% (315327 hits and 254064 misses)。

一是memcache随时有可能丢失数据;二是有些数据不能把缓存时间设得太长;三是一旦有更新,很多缓存必须删除。

而且就算命中率是100%,以V2EX这1万多篇文章举例,搜索引擎爬个几千篇就没了…
2011-09-06 22:19:56 +08:00
回复了 panlilu 创建的主题 问与答 大家有关于ipad3的消息么?
@panlilu 据说因为产能不够,明年3月才能出
2011-09-06 17:54:58 +08:00
回复了 jeeson 创建的主题 Google App Engine GAE 新定价下, instance hours 没那么可怕
@Livid 准确来说不是datastore的读写次数,而是entity、key和index的读写次数。

假如打开V2EX首页显示20篇文章,那么需要20篇文章+20用户信息=40次entity fetch。别忘了还有节点,每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。

而在文章页,每篇回复也包含用户信息,因此相当于2次entity fetch。

而免费配额是每天5万次Datastore Reads操作,即使使用memcache,也只有访问量很小的站才能不超过这个配额。
2011-09-04 13:16:52 +08:00
回复了 Livid 创建的主题 设计 貌似现在很流行这样的红色 + 纸黄色的设计
Flipboard、网易阅读、ZAKER和昨天出的中文摄影杂志 for iPad也是这种色调,感觉最早采用的应该是Reeder吧。
2011-09-03 21:21:54 +08:00
回复了 summic 创建的主题 MySQL mysql 子查询遇到诡异问题,求指点
这个例子应该可以直接用inner join吧…

不到万不得已不用子查询
2011-09-03 21:16:28 +08:00
回复了 amyhyde 创建的主题 分享发现 http://jintao.hu/ 很牛的域名
居然没被墙
2011-09-02 17:14:33 +08:00
回复了 kingrever 创建的主题 问与答 请问一下如google+信息分享的数据库设计。
@kingrever 大概就这样吧:
Message.filter('direct_to =', current_user)
Message.filter('sender IN', current_user.follower).filter('status =', 'public')
Message.filter('circle IN', current_user.circles)
2011-09-02 16:06:04 +08:00
回复了 kingrever 创建的主题 问与答 请问一下如google+信息分享的数据库设计。
没有证据表明Google+是用关系数据库吧…

如果是用GAE的datastore的话,信息表里就保存了公开状态了(public,some circle,somebody)。用户只要进行3个查询,然后merge一下就能获取自己的timeline了。
2011-09-02 02:13:32 +08:00
回复了 Livid 创建的主题 Google App Engine Google App Engine 即将从 Preview 阶段毕业
@phus 看不出任何优化,application的创建倒是需要移到main函数外面……
2011-09-01 23:40:22 +08:00
回复了 haohaolee 创建的主题 问与答 如何对抗ISP的http劫持?
我是在最开始插入这段代码:
<script>if (top !== self) top.location = self.location;</script>
Azure价格是稳定,不过比GAE贵==
2011-09-01 11:08:53 +08:00
回复了 Livid 创建的主题 Google App Engine Google App Engine 即将从 Preview 阶段毕业
@sohoer 影响不大。马上会支持Python 2.7(从billing history看估计是November 20th, 2011),到时候一个instance可以同时响应多个请求。

另外发现这几天的数据库读取次数都刚好超过50k,看来得优化了=。=
2011-09-01 10:53:41 +08:00
回复了 Livid 创建的主题 Google App Engine Google App Engine 即将从 Preview 阶段毕业
看到几个抱怨的,大应用还是果断撤离吧:

I am one of them. Monthly charge: $900 -> $2850 (310%)

Our costs went up 2800% under the new pricing.

We are going from $5,400/month to $26,500/month (Python) - and this is
only one of our apps.

I am not in the same league as those who pay thousands of dollars per
month but rather the average small developer who sees what was a 31 $
monthly bill jump to over 500 $.
2011-09-01 10:45:37 +08:00
回复了 Livid 创建的主题 Google App Engine Google App Engine 即将从 Preview 阶段毕业
这个价格几个月前就定下了,曾经向Google提议把24 Instance Hours增加到25,他们回复说可以考虑考虑,但是就没下文了…

数据库操作收费的原因是:现在不按API CPU时间收费了,只看API调用次数。

以我的blog为例,今天19小时数据库调用29350次,使用0.17 CPU时间。按之前的方法计算为$0.10 * 0.17 = $0.017,按新方法计算为29350 / 10k * 0.01 = $0.029。

虽然也贵不了多少,但免费配额确实太少了,只有50k次。
仍以我的blog为例,19小时用了5% CPU,理论上免费配额可以支持20倍访问量。但调用次数已经达到50k的60%,基本上没多少扩展空间了。

然后是如果收费,至少每个月$9,哪怕你原本只需要支付$0.01。
2011-08-31 10:54:49 +08:00
回复了 walkingway 创建的主题 3G 大家有没有觉着联通的3G流量消耗的太快了
每个月剩90%流量没用的路过…看来是太宅了
2011-08-30 13:48:18 +08:00
回复了 irong 创建的主题 iPhone iPhone上什么Rss阅读器好呢?
不知道为什么都推荐Reeder,真正用起来就一堆恼火的问题。例如排版经常出现滚动条(而且经常滚着滚着就到右边了),直接显示全部条目而非分页(导致无法只将一部分条目标记为已读)。

MobileRSS的离线缓存功能是渣,谁用谁知道。

目前感觉iReadG是唯一没啥大毛病的,虽然也存在各种不爽,例如标记已读时阻塞主线程。
2011-08-30 13:28:54 +08:00
回复了 wickila 创建的主题 Python 自学python的一些感受,前辈们给点建议
@wickila 不知道你看的是什么文档。

如果你是用Windows的话,Python的Doc文件夹下会有个pythonxxx(版本号).chm。打开以后选择index,输入Element,第一条就是“Element() (in module xml.etree.ElementTree)”,进去后翻到最上面或最下面,也会显示模块名。

就算没有文档的话,也可以在命令行里显示出来:
>>> Element('a').__class__
<class xml.etree.ElementTree._ElementInterface at 0x00E014B0>
_ElementInterface就是类名,前面的就是模块名。
2011-08-29 23:33:36 +08:00
回复了 codeplay 创建的主题 问与答 for循环中的类型(Python)
@codeplay 要说明它的原理有点复杂,总的来说是这样的:os.walk()生成了一个generator对象,for循环会调用这个对象的next()方法,这个next方法返回了一个含3个元素的tuple,分别对应到root,dirs,files变量。

我的感觉是你似乎不太清楚for的这种用法,举个例子来说吧:
for x, y in [(1, 2), (3, 4)]:...
它实际上是这样的缩写:
for (x, y) in [(1, 2), (3, 4)]:...
于是第一次循环中,(x, y)就被带入了(1, 2),即
(x, y) = (1, 2)
而它又相当于
x = 1
y = 2

至于generator嘛,我就拿个简单的例子来说:
def f():
yield 1, 2
yield 3, 4

g = f()
print g.next()
print g.next()
print g.next()

输出结果是:
(1, 2)
(3, 4)
Traceback (most recent call last):
print g.next()
StopIteration

可以看到,每次next()方法都会返回yield表达式的结果,当没有更多的yield时,就会抛出StopIteration异常。

而用在for循环里的时候,Python runtime会自动捕捉StopIteration异常,并停止当前循环:
for x, y in f(): print x, y
1 ... 33  34  35  36  37  38  39  40  41  42 ... 53  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1804 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 16:32 · PVG 00:32 · LAX 09:32 · JFK 12:32
Developed with CodeLauncher
♥ Do have faith in what you're doing.