GAE 新定价下, instance hours 没那么可怕

[jeeson]

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划算.

[phus]

看来Python 2.7值得期待的。

[fcicq]

GAE/Java or Go 没有特别大的参考价值. 楼主也没有说上面跑的什么样的 load. 依赖 db 和 urlfetch 的应用还是赶紧搬走的好, 无论是 HRD 还是 Master-Slave.

[Livid]

新的定价模型里最可怕的是按照 datastore 的读写次数进行收费。

幸好 Google 还没有变态到按照 memcache 的读写次数收费。

[keakon]

@Livid 准确来说不是datastore的读写次数，而是entity、key和index的读写次数。

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

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

而免费配额是每天5万次Datastore Reads操作，即使使用memcache，也只有访问量很小的站才能不超过这个配额。

[mywaiting]

@keakon 这个:( 汗!

[darcy]

谷歌越来越小气，先是关掉一大堆东西，再是减少配额提高价格，原来免费的变成收费，收费的改变计费方式。

[CoX]

@keakon 按照你这个说法，那更恐怖了

[jeeson]

@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的写操作, 主要是计数器, 可以用异步批量写入.

[fcicq]

100% 命中率又如何? 命中率高不能掩盖高价的事实.

咱看看 EBS 的 pricing. $0.10 per 1 million IO, 虽然偶觉得这已经很高了.
GAE: $0.01 / 10k operations.

IO 与 operations 的比例比较说明问题. 虽然 GAE 是 HRD, 但并不意味着就可以收 n 倍的钱. 熟悉 MySQL 的同学应该知道 show status 显示什么, 自己换算一下会很吓人的.

[jckwei]

@keakon 早期，看过V2EX的代码后，感觉很浪费GAE资源，因为又特别喜欢这种形式，就仿着做了一个GAE-BBS，虽然GAE读比写快、省很多，但还是尽量减少读，如同说过的V2EX读一个帖子需要 读帖子+用户+用户头像（头像还有三种尺寸），设计时就把用户和头像省掉，只需读取一次帖子信息。但要花费一些空间来存储，每个帖子估计多出50-80个字节（包含Metadata）。

希望免费下能承载更多。

使用了你早期的YUI，很好用。

[lfeng]

@jckwei 加上memcache，命中率高点的话你说的这个问题基本可以忽略了吧。

[keakon]

@jeeson @lfeng 高不了的…我几乎对所有的数据库访问加了缓存，目前的状态是Hit ratio: 55% (315327 hits and 254064 misses)。

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

而且就算命中率是100%，以V2EX这1万多篇文章举例，搜索引擎爬个几千篇就没了…

[lfeng]

@keakon 改进缓存策略和算法，可以提升到80％－90％，memcache本身的作用就只是数据缓存（或者说活跃数据）来减小数据库读写压力，虽然有一些持久化的项目，但那些项目现在看实际也是一种NoSQL的实现。

P.S 我觉得你想法，太过极端了。。。。

[jeeson]

@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 (可能要翻墙访问)

[jckwei]

@lfeng memcache 对像V@EX这样的帖子更新速度快的没有多大作用，使用 memcache 应该权衡更新频率和浏览刷新频率。其实任何东西做大了都要考虑自身的特点，如v2ex：用户多、帖子多、浏览多，如果不能兼顾的话就要有所牺牲，看哪个便宜，比如GAE新政策之前如果存储比CPU时间便宜就应该用存储空间来照顾。

谁知道GAE调整，以后估计还会调整。

对于成本和性能，不同的人有不同的选择，如@Livid 可能更注重网站功能，@keakon 可能更注重性能。

[keakon]

@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配额已经用完了，而这花不了几秒…

[sohoer]

@keakon 一句话你的博客有这么大的更新量吗，就算有你也可以不去实时更新视图缓存。

[keakon]

@sohoer 更新量不大，小的更新我都不会去删除缓存。

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

再给个数据吧，我每天的请求数是2万多，Datastore Reads是7万多。这几天优化过后变成5万了，昨晚又优化了一个地方，但估计只能降到4万，几乎没多少增长空间了。
2万/天请求换算成秒只相当于0.2 QPS，而实际上平均0.1秒就能处理一个请求。也就是说，免费配额虽然给了一个免费的instance，但80%的时间都必须让它空闲着。

[sohoer]

@keakon "因为memcache有55%的命中率。"
嗯，大概是你博客数据比较多，已至于memcache缓存数据丢失。

[ayanamist]

@sohoer memcache很容易丢的，从我的应用来看，memcache命中率随着用户的增长从80%多一路下滑到48%，而且从log情况看，cache的时间远没有你设置的timeout那么长，我一分钟的timeout，居然在几秒内也就没了。