现在加入了一些更多的优化。

接下来就是做主题分页了。

我研究下看看 Python 标准库里有没有什么靠谱的压缩手段。

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.

囧了。。。

其实我记得目前页面上的回复是有缓存的。

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

我再仔细看看文档。

@Los 确实是 spammer。我已经 deactivate 这个账户很多次。但是每次都很顽强地把密码找回之后继续发。

目前 V2EX 的 deactivate 机制就是把一个用户的密码改为乱码，这样他就暂时不能登陆。

@ashchan 非常感谢你的思路。

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

目前对于主题的 content 已经使用了将渲染结果保存为 content_rendered 的方法来优化，但是对 reply 也这样做的话，长远会消耗 2 倍的存储空间，所以我还在考虑中。

@Los 呵呵，希望这里很快也会成为一个各种网站的流量源，就像 Digg 和 Reddit 那样。

为什么不直接用 SQLite 把这些数据存到 iPhone 里呢？

可以在浏览器端用 JS 把内容藏起来，V2EX 的 block 就是这样实现的。

eBay 的本质在于帮助人与人之间沟通并愉快地达到目的，真正对于用户有触动和帮助的是其中的沟通和感受。设计确实丑了一点，但是一个 3000 万行 Java 和 C++ 的 codebase（现在估计更大了）不是谁想改就可以改的。

技术和设计对于一个刚开始的网站很重要，但是所有的大型网站到了后期，重要的都是运营。

@GordianZ 我想或许是因为文化吧。

eBay 的核心文化中有一条 people are basically good，即相信人性本善，于是他们所有的产品设计和运营都是围绕这条来的。

在我离开 eBay 3 年多之后，我还是依然记得这句话。

而一个用了 datastore/memcache，带有 session 的页面，在 GAE 上渲染至少要 100~200 ms。差不多是传统 LAMP 的 10 倍。

这是 Python 的真实情况，不知道 Java 会如何。

/t/815 这样的超长帖子，在 GAE 上渲染会超过 1000ms，而这个帖子是昨天的热点。

如果各位有什么好的优化方法（除了分页之外），还希望多多赐教。

这是统计 Analytics 流量的 app：

http://itunes.apple.com/us/app/analytics-pro/id352409235?mt=8

我的愿景：

http://picky.olivida.com/cloud-future

无论发生什么，我会把这个项目一直坚持下去。

国内的用户对于自己的数据实在是没有任何安全感。这是一个很大的障碍。

嗯，我这里起码可以打开 vip.wordpress.com