@claliu 这篇文章真长, 并且很有营养, 埋在这个帖子里太浪费了

商业价值 杂志, 果壳, 科学松鼠会, 文字多, 适合在Kindle或手机上阅读

yankodesign 许多非常酷的设计, ArchDaily 建筑设计. 图多, 看腻了技术类的博客, 很适合调剂一下

可以用其它国家的Google Reader, 例如:
https://www.google.co.uk/reader/ , https://www.google.co.jp/reader/

北京联通访问 www.v2ex.com 也是极度的慢, 后来在路由器里设置DNS (原先是自动获得DNS), 速度飞快. 关键是我设置的DNS就是北京联通的DNS: 202.106.196.115 和 202.106.46.151

fast.v2ex.com 无法访问, 北京联通

转一篇文章, 跑步的产品需求: http://content.businessvalue.com.cn/post/4485.html

@sparklo 国内也很多 http://s.taobao.com/search?q=ForeRunner&keyword=&commend=all&ssid=s5-e&search_type=item&atype=&tracelog=&sourceId=tb.index&rt=1316310123003

我用的是早期的ForeRunner 301, 屏幕够大

Android 下RunKeeper也用过, 做的不错, 不过跑步时带个手机/iPod太大了

跑步环境 > 跑鞋 > 排汗速干内衣 > 其它

@z 原来如此, 谢谢

Garmin ForeRunner, 带GPS, 有的版本带心电测试, 防水, 曾经游泳时测试过

用于跑步, 徒步, 骑车, 滑雪 等各项运动都可以, 有训练记录, 可以配合软件分析, 还带有虚拟训练伴侣, 一个人训练时很不错

部分型号有时特别便宜

@chuck911 是的 :)

是后台运行iPhone模拟器

http://www.quora.com/How-does-the-technology-behind-Pieceables-iOS-viewer-work

Instance Hours 对应于CPU Hours 而言的

先说CPU Hours: 一个请求, 如果耗费 0.1s, 那么计费时就按照 0.1s累计. 假设每天100K请求, 那么就是 100K*0.1s = 10Ks, 约2.8 CPU Hours.

而Instance Hours 是指Instance的保持时间, 不管是否在处理请求 (这里的Instance 和Amazon的Micro Instance差不多)

GAE的Instance数量是动态, 并且创建后通常会在空闲一段时间(15分钟?)后才释放

之前CPU Hours对于小规模应用很合算, 基本不会超过6.5小时的免费限额

而现在新价格下, 虽然有24小时的Instance Hours, 但是一旦有突发大量请求, 一个Instance处理不过来的时候, 就会产生第二, 第三个Instance..., 于是就会有费用产生.

关键是, GAE/Python目前不支持并发请求, 一个Instance只能顺序处理逐个请求, 于是对于并发请求很多的应用, 就会产生"惊人"的收费, 而真正的CPU使用率很低

简单来说, 之前CPU Hours惊人的便宜, 现在Instance Hours惊人的昂贵, 在没有支持并发请求的情况下.

用超级ping看看 http://ping.chinaz.com, 从国内各个地区测试, 比较适合国内的网络环境.

如果都没有问题, 试试重新启动路由器, 有时会恢复

现在正常了

用 超级ping (http://ping.chinaz.com/) 测试了一下, 电信, 移动可以, 联通大部分不行

北京联通不行

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

@manhere 谢谢. 抱歉, 竟然贴错地址.

昨天从 http://www.ifanr.com/51548 发现 Make Things这篇文章, 其中有句话:

Freeman Dyson : “There is a great satisfaction in building good tools for other people to use.”
“为他人创造优良的工具，乐在其中”

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

美国东海岸, 用来做备用, 不灵.

@Los 我的意思是没有绝对安全的 :)

readwriteweb 这篇文章在 HN上的讨论, 很热烈: http://news.ycombinator.com/item?id=2954352

其中 App Engine team 成员 nicksdjohnson 解释了 CPU hours 和 Instance hours 区别, 并再度提到 Python 2.7 的 multiple concurrent requests 将...

好吧, 就算这样吧, 似乎也是这样. 可是, Google 为什么不等 Python 2.7 出来后再做价格对比呢?