推荐学习书目
› Python Cookbook
› Using Google App Engine
推荐下载
› Latest Google App Engine SDK
其他兼容技术
› AppScale
GAE 新定价下, instance hours 没那么可怕
jeeson · 2011-09-06 11:45:42 +08:00 · 7557 次点击这是一个创建于 4862 天前的主题，其中的信息可能已经有所发展或是发生改变。
GAE/Java, 启用了并发请求几天, 一些结果分享:
之前instance经常跑到5以上, 启用并发请求后, 极少跑到3， 基本都在1， 偶尔跑到2.
跑到3是大量的突发请求, 跑到2倒不一定是负载大
没做其它优化, 只是在 Application Settings 中, 把Min Pending Latency 修改为3秒. 第一天Min Pending Latency为自动的时候, 跑到2会更频繁一些.
***启用多线程后, 内存并没有明显增加
***Python运行内存比Java小很多 (Java经常跑到90M以上), 并且加载速度快, 所以Python 2.7以后, 一个instance的响应能力提高可能会比Java高更多
=============
虽然GAE计价时CPU按照1G来计算, 但是有人测试过, 实际CPU相当于1.8G. 内存据称是200M, 但是跑到300M才会被结束.
对比Windows Azure, Amazon AWS, 同价位下GAE内存明显小很多, 并且没有不同档次可选择. 但GAE是运行内存.
GAE的instance数量是动态的, 这个是云计算的最大优点. 试想一下, 一个应用, 如果白天高峰时段需要很多instance, 而晚上1个instance就可以满足需要, 用Azure或AWS目前只能创建最大计算能力的instance, 算下来可能还是GAE划算.
之前instance经常跑到5以上, 启用并发请求后, 极少跑到3， 基本都在1， 偶尔跑到2.
跑到3是大量的突发请求, 跑到2倒不一定是负载大
没做其它优化, 只是在 Application Settings 中, 把Min Pending Latency 修改为3秒. 第一天Min Pending Latency为自动的时候, 跑到2会更频繁一些.
***启用多线程后, 内存并没有明显增加
***Python运行内存比Java小很多 (Java经常跑到90M以上), 并且加载速度快, 所以Python 2.7以后, 一个instance的响应能力提高可能会比Java高更多
=============
虽然GAE计价时CPU按照1G来计算, 但是有人测试过, 实际CPU相当于1.8G. 内存据称是200M, 但是跑到300M才会被结束.
对比Windows Azure, Amazon AWS, 同价位下GAE内存明显小很多, 并且没有不同档次可选择. 但GAE是运行内存.
GAE的instance数量是动态的, 这个是云计算的最大优点. 试想一下, 一个应用, 如果白天高峰时段需要很多instance, 而晚上1个instance就可以满足需要, 用Azure或AWS目前只能创建最大计算能力的instance, 算下来可能还是GAE划算.
 |
1
phus 2011-09-06 12:07:42 +08:00
看来Python 2.7值得期待的。
|
 |
2
fcicq 2011-09-06 16:52:35 +08:00
GAE/Java or Go 没有特别大的参考价值. 楼主也没有说上面跑的什么样的 load. 依赖 db 和 urlfetch 的应用还是赶紧搬走的好, 无论是 HRD 还是 Master-Slave.
|
 |
3
Livid MOD 新的定价模型里最可怕的是按照 datastore 的读写次数进行收费。
幸好 Google 还没有变态到按照 memcache 的读写次数收费。 |
 |
4
keakon 2011-09-06 17:54:58 +08:00
@Livid 准确来说不是datastore的读写次数，而是entity、key和index的读写次数。
假如打开V2EX首页显示20篇文章，那么需要20篇文章＋20用户信息＝40次entity fetch。别忘了还有节点，每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。 而在文章页，每篇回复也包含用户信息，因此相当于2次entity fetch。 而免费配额是每天5万次Datastore Reads操作，即使使用memcache，也只有访问量很小的站才能不超过这个配额。 |
 |
6
darcy 2011-09-06 17:57:14 +08:00
谷歌越来越小气，先是关掉一大堆东西，再是减少配额提高价格，原来免费的变成收费，收费的改变计费方式。
|
 |
8
jeeson OP @keakon @Livid @fcicq datastore 部分我没优化. 我的Java应用是通过Objectify来操作datastore, Objectify内置了cache支持, 只要在class前加上 @cache 就可以对该对象的实例进行cache(读), 可以通过Filter实现异步cache (写)
@keakon "假如打开V2EX首页显示20篇文章，那么需要20篇文章＋20用户信息＝40次entity fetch。别忘了还有节点，每个节点都算一次entity fetch。于是访问一次首页要超过100次Datastore Reads操作。" v2ex 如果使用Memcache, cache命中率应该会很高. 比如, 最新的n条回复都保存在Memcache中, 这样可以大大降低读操作. 而datastore的写操作, 主要是计数器, 可以用异步批量写入. |
|
9
fcicq 2011-09-06 18:54:47 +08:00
100% 命中率又如何? 命中率高不能掩盖高价的事实.
咱看看 EBS 的 pricing. $0.10 per 1 million IO, 虽然偶觉得这已经很高了. GAE: $0.01 / 10k operations. IO 与 operations 的比例比较说明问题. 虽然 GAE 是 HRD, 但并不意味着就可以收 n 倍的钱. 熟悉 MySQL 的同学应该知道 show status 显示什么, 自己换算一下会很吓人的. |
 |
10
jckwei 2011-09-07 08:25:57 +08:00
@keakon 早期，看过V2EX的代码后，感觉很浪费GAE资源，因为又特别喜欢这种形式，就仿着做了一个GAE-BBS，虽然GAE读比写快、省很多，但还是尽量减少读，如同说过的V2EX读一个帖子需要 读帖子+用户+用户头像（头像还有三种尺寸），设计时就把用户和头像省掉，只需读取一次帖子信息。但要花费一些空间来存储，每个帖子估计多出50-80个字节（包含Metadata）。
希望免费下能承载更多。 使用了你早期的YUI，很好用。 |
|
12
keakon 2011-09-07 09:59:35 +08:00
|
 |
13
lfeng 2011-09-07 10:20:17 +08:00
@keakon 改进缓存策略和算法，可以提升到80％－90％，memcache本身的作用就只是数据缓存（或者说活跃数据）来减小数据库读写压力，虽然有一些持久化的项目，但那些项目现在看实际也是一种NoSQL的实现。
P.S 我觉得你想法，太过极端了。。。。 |
|
14
jeeson OP @keakon 我还没有做过这些优化, 也没试验验证过, 以下只是推测
首先, 如果可以按最高使用频率来cache, 肯定比常规FIFO方式更合适, 而这个恰恰在v2ex具备条件(推测). 比如, cache最新的n条回复, 以及最新回复的n位用户. 然后, 只在发生写操作时cache (用户发帖子/回复的时候, 不包括计数器之类的操作), cache该用户信息和发帖/回复信息. (初始加载时, 可能需要加载最新的n条信息) "一是memcache随时有可能丢失数据；二是有些数据不能把缓存时间设得太长；三是一旦有更新，很多缓存必须删除。" 一,二点同意, 选择合适的cache规模应该可以克服 =============================== 假如, datastore访问是通过get, put, 那只要在put时, 顺便放入cache, get时先检查cache 如果是通过query然后逐条读取, 或者批量读写, Python我不了解, Java/Objectify因为在中间架了一层, 所以所有操作都支持cache GAE/Java 因为原生数据接口非常不方便, 效率底下, 所以有许多第三方的接口: http://blog.cogipard.org/articles/tag/datastore (可能要翻墙访问) |
|
15
jckwei 2011-09-07 10:55:10 +08:00
|
|
16
keakon 2011-09-07 12:28:53 +08:00
@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配额已经用完了，而这花不了几秒… |
Select Language