20100909

2010-09-09 03:43:52 +08:00
 Livid
关于昨天的 downtime 及更多的一些思考。

http://picky.olivida.com/20100909
5889 次点击
所在节点    V2EX
22 条回复
xiaojay
2010-09-09 08:11:47 +08:00
@livid 这个gae流量统计软件是iphone什么app?
Livid
2010-09-09 08:13:38 +08:00
byron
2010-09-09 08:52:24 +08:00
@Livid 好贵。下了下狠心,还是没买。
apple
2010-09-09 08:59:50 +08:00
@kyron 开复的创新工厂不是开发了一个移动互联网的统计么?去试试他的
ashchan
2010-09-09 09:08:03 +08:00
出乎意料,14K的PV居然就会超出GAE的默认CPU限制。
Livid
2010-09-09 09:11:36 +08:00
/t/815 这样的超长帖子,在 GAE 上渲染会超过 1000ms,而这个帖子是昨天的热点。

如果各位有什么好的优化方法(除了分页之外),还希望多多赐教。
Livid
2010-09-09 09:14:23 +08:00
而一个用了 datastore/memcache,带有 session 的页面,在 GAE 上渲染至少要 100~200 ms。差不多是传统 LAMP 的 10 倍。

这是 Python 的真实情况,不知道 Java 会如何。
Kenyth
2010-09-09 10:55:00 +08:00
@Livid 从我的经验Java比Python实现的没有性能优势,有时候甚至性能更差,就datastore来说,Java实现官方推荐的不是low-level api,而是JDO/JPA,我几个月前用的时候有些操作你甚至都不能用到性能最优的low-level api,因为已经被抽象过了。
ashchan
2010-09-09 14:07:48 +08:00
GAE除了 memcached,可以进行静态缓存吗?如果不行,可否尝试直接在memcached中缓存页面片断。另外,象/t/815这类页面,回复内容可以根据最后更新时间和post为key进行缓存,各个回复上的 x hours, x minutes ago可以通过JS来实现从而将性能负载转移到客户端。用户登录的所有相关页面部分也可以以JS的方式来通过另一个request来加载。
e6nian
2010-09-09 14:12:14 +08:00
babel 和gae 如果支持master-slave的分布式部署就不成问题了.
一个nginx 前段,后端带上N个GAE.
minghua
2010-09-09 14:59:49 +08:00
@apple Livid 说的统计Analytics 流量的app是google Analytics的客户端,是网站流量统计。

创新工场的友盟(http://www.umeng.com) 是 app 使用情况的统计服务,目前有iPhone,android sdk。
huacnlee
2010-09-09 23:53:43 +08:00
@ashchan JS异步加载登录状态的体验非常不好,我现在的项目就是这样弄的,都准备去掉了,但一直没更好的方案。

缓存用最后回复时间这个方法不错,受教了,这种方式应该都可以把清除动作省下了,以Memcached 的过期机制的话
Livid
2010-09-09 23:59:51 +08:00
@ashchan 非常感谢你的思路。

Django 的 template filter 也是消耗 CPU 的另一源头,目前页面上的 x hours xx seconds ago 即是通过 template filter。如果能够将这些负载挪到浏览器,对性能肯定有帮助。

目前对于主题的 content 已经使用了将渲染结果保存为 content_rendered 的方法来优化,但是对 reply 也这样做的话,长远会消耗 2 倍的存储空间,所以我还在考虑中。
apple
2010-09-10 00:01:30 +08:00
@e6nian 这个方法比较邪恶。就是申请N个免费gae的流量,集中到一个站去使用。我曾经这么想过,但是恐怕google有对策,而且效率也是个问题。
huacnlee
2010-09-10 00:07:29 +08:00
如 @ashchan 说所的,如果将回复列表HTML结果缓存掉,节省下来的东西会有很多。只不过用户信息改变后的同步会成问题,不过还好现在只有头像和用户名,用户名是无法改的,没问题,头像的话可以改为动态的地址,像Gavater那样用ID或用户名到一个固定地址获得图片,如 http://v2ex.com/avater?id=67
Livid
2010-09-10 00:11:53 +08:00
其实我记得目前页面上的回复是有缓存的。

但是 /t/815 为什么还那么慢,有一种可能就是,memcache 能够接受的对象尺寸有限制?比如 1M,但是 /t/815 很可能超过 1M 了。

我再仔细看看文档。
Livid
2010-09-10 00:15:01 +08:00
http://code.google.com/appengine/docs/python/memcache/clientclass.html#Client_set

set(key, value, time=0, min_compress_len=0, namespace=None)

Sets a key's value, regardless of previous contents in cache.

Arguments:

key

Key to set. The Key can be a string or a tuple of (hash_value, string) where the hash_value, normally used for sharding onto a memcache instance, is instead ignored, as Google App Engine deals with the sharding transparently.

value

Value to set. The value type can be any value supported by the Python pickle module for serializing values. The combined size of the serialized key and value must be at most 1 megabyte.

囧了。。。
Livid
2010-09-10 00:16:00 +08:00
我研究下看看 Python 标准库里有没有什么靠谱的压缩手段。
Los
2010-09-10 00:27:26 +08:00
@Livid 分页,没办法不考虑一下这最靠谱的解决方法了。
zhendi
2010-09-10 00:33:23 +08:00
压缩的话,可以试试zlib模块:
http://docs.python.org/release/2.5.2/lib/module-zlib.html

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/2411

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX