V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
DAOCLOUD
推荐学习书目
Python Cookbook
Using Google App Engine
推荐下载
Latest Google App Engine SDK
其他兼容技术
AppScale
jeeson
V2EX  ›  Google App Engine

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

  •  
  •   jeeson · 2011-09-06 11:45:42 +08:00 · 7526 次点击
    这是一个创建于 4812 天前的主题,其中的信息可能已经有所发展或是发生改变。
    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划算.
    20 条回复    1970-01-01 08:00:00 +08:00
    phus
        1
    phus  
       2011-09-06 12:07:42 +08:00
    看来Python 2.7值得期待的。
    fcicq
        2
    fcicq  
       2011-09-06 16:52:35 +08:00
    GAE/Java or Go 没有特别大的参考价值. 楼主也没有说上面跑的什么样的 load. 依赖 db 和 urlfetch 的应用还是赶紧搬走的好, 无论是 HRD 还是 Master-Slave.
    Livid
        3
    Livid  
    MOD
       2011-09-06 16:55:42 +08:00
    新的定价模型里最可怕的是按照 datastore 的读写次数进行收费。

    幸好 Google 还没有变态到按照 memcache 的读写次数收费。
    keakon
        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,也只有访问量很小的站才能不超过这个配额。
    mywaiting
        5
    mywaiting  
       2011-09-06 17:56:48 +08:00
    @keakon 这个:( 汗!
    darcy
        6
    darcy  
       2011-09-06 17:57:14 +08:00
    谷歌越来越小气,先是关掉一大堆东西,再是减少配额提高价格,原来免费的变成收费,收费的改变计费方式。
    CoX
        7
    CoX  
       2011-09-06 18:06:21 +08:00
    @keakon 按照你这个说法,那更恐怖了
    jeeson
        8
    jeeson  
    OP
       2011-09-06 18:36:12 +08:00
    @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
        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 显示什么, 自己换算一下会很吓人的.
    jckwei
        10
    jckwei  
       2011-09-07 08:25:57 +08:00
    @keakon 早期,看过V2EX的代码后,感觉很浪费GAE资源,因为又特别喜欢这种形式,就仿着做了一个GAE-BBS,虽然GAE读比写快、省很多,但还是尽量减少读,如同说过的V2EX读一个帖子需要 读帖子+用户+用户头像(头像还有三种尺寸),设计时就把用户和头像省掉,只需读取一次帖子信息。但要花费一些空间来存储,每个帖子估计多出50-80个字节(包含Metadata)。

    希望免费下能承载更多。

    使用了你早期的YUI,很好用。
    lfeng
        11
    lfeng  
       2011-09-07 09:08:32 +08:00
    @jckwei 加上memcache,命中率高点的话你说的这个问题基本可以忽略了吧。
    keakon
        12
    keakon  
       2011-09-07 09:59:35 +08:00
    @jeeson @lfeng 高不了的…我几乎对所有的数据库访问加了缓存,目前的状态是Hit ratio: 55% (315327 hits and 254064 misses)。

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

    而且就算命中率是100%,以V2EX这1万多篇文章举例,搜索引擎爬个几千篇就没了…
    lfeng
        13
    lfeng  
       2011-09-07 10:20:17 +08:00
    @keakon 改进缓存策略和算法,可以提升到80%-90%,memcache本身的作用就只是数据缓存(或者说活跃数据)来减小数据库读写压力,虽然有一些持久化的项目,但那些项目现在看实际也是一种NoSQL的实现。

    P.S 我觉得你想法,太过极端了。。。。
    jeeson
        14
    jeeson  
    OP
       2011-09-07 10:34:33 +08:00
    @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
        15
    jckwei  
       2011-09-07 10:55:10 +08:00
    @lfeng memcache 对像V@EX这样的帖子更新速度快的没有多大作用,使用 memcache 应该权衡更新频率和浏览刷新频率。其实任何东西做大了都要考虑自身的特点,如v2ex:用户多、帖子多、浏览多,如果不能兼顾的话就要有所牺牲,看哪个便宜,比如GAE新政策之前如果存储比CPU时间便宜就应该用存储空间来照顾。

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

    对于成本和性能,不同的人有不同的选择,如@Livid 可能更注重网站功能,@keakon 可能更注重性能。
    keakon
        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配额已经用完了,而这花不了几秒…
    sohoer
        17
    sohoer  
       2011-09-07 13:19:17 +08:00
    @keakon 一句话你的博客有这么大的更新量吗,就算有你也可以不去实时更新视图缓存。
    keakon
        18
    keakon  
       2011-09-07 13:34:02 +08:00
    @sohoer 更新量不大,小的更新我都不会去删除缓存。

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

    再给个数据吧,我每天的请求数是2万多,Datastore Reads是7万多。这几天优化过后变成5万了,昨晚又优化了一个地方,但估计只能降到4万,几乎没多少增长空间了。
    2万/天请求换算成秒只相当于0.2 QPS,而实际上平均0.1秒就能处理一个请求。也就是说,免费配额虽然给了一个免费的instance,但80%的时间都必须让它空闲着。
    sohoer
        19
    sohoer  
       2011-09-07 15:42:22 +08:00
    @keakon "因为memcache有55%的命中率。"
    嗯,大概是你博客数据比较多,已至于memcache缓存数据丢失。
    ayanamist
        20
    ayanamist  
       2011-09-10 13:47:56 +08:00
    @sohoer memcache很容易丢的,从我的应用来看,memcache命中率随着用户的增长从80%多一路下滑到48%,而且从log情况看,cache的时间远没有你设置的timeout那么长,我一分钟的timeout,居然在几秒内也就没了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2545 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 15:34 · PVG 23:34 · LAX 07:34 · JFK 10:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.