Google App Engine 使用总结
从3月份到今天，搭建在GAE上的网站在一步步走向平稳，没有大肆宣传，当前访问量不是很高，所以一直是在免费限额的范围当中。在开发过程中，走了不少弯路，也遇见了不少新问题。
配额介绍：
1）Instanced Hour免费限额为28IH(Instanced Hour)，每Web页按350KB计，平均加载此页面需要耗费掉0.001IH，28/0.001=28000，在单次访问、不考虑缓存的情况下基本等于2.8w页/人/次.如果是内容博客等结构单一的网站基本上能够满足要求。
2）Database StoreDatabase是开发过程中首先碰到限额天花板的一项，最突出的是Database Small Operation，它的统计数据来自于GQL（Google开发的一套类SQL的数据库操作语句）中基于Key的查询，比如SELECT key FROM Person，这种语句都会统计到Small Operation中。这种查询在程序中使用频率不是很高，大部分情况下会采用 SELECT * FROM Person。对于在数据库中以Blob类型存储大量图片的web应用来说可能会是一场灾难，因为图片的访问是以db.get(Key)的方式查询，频繁地图片访问，很快就会将Small Operation的限额给冲破。前期开发的时候全部使用自己存储图片，然后Key查询的方式访问，没过几天就被冲破限额，没法访问了，只能速度修改程序，改为访问外链展示图片，此后这一项再也没有超出限额，感觉就是在带着脚镣跳舞，自得其乐的感觉。Data Read Operation限额增长速度没有做过多统计，当然这个超出限额只能是收费扩展了，因为访问的不断增长，再怎么优化也是徒劳无功的。
3）Data Index限额200，基本上能够满足小型网站的要求。现在总共有13张表，43个非重复字段，总共建立20个索引。在数据库访问中，所有的条件查询，GAE都要求建立索引，如若需要需要额外的索引，可以自行添加到index.yaml中。
主要的限额会集中在前段IH以及数据库访问上面，其他Urlfetch、XMPP、Task Queues、Deployments能够满足基本需求。当然如果是多人开发，真实环境测试还是需要考虑Deployments每天限额1000次的发布。
注意点：
1）静态文件路径需要在app.yaml单独配置访问的URL
2)SELECT * FROM X 要比SELECT key FROM X要比花费更多的CPU时间，当然前提是你要保证key方式也不会过快的超出限额。
3）Task Queues作为一种后台自动执行请求的方式，一定要保证测试通过，否则一旦出错，它将会以时间递增的间隔重复执行，直到达到时间最大值停止，但是CPU时间和数据库访问可能会为此而耗干。
4）Email API发件人必须是本应用的开发管理员、当前的登录的Google Account账户邮箱或者本应用内的有效邮箱地址比如string@appid.appspotmail.com否则邮件只会发送失败。
5）独立域名你可以通过免费开通Google Apps，然后将GAE应用添加到你的Google Apps服务中去，再将Google Apps中设置好的域名指向你创建GAE应用时的appid.appspot.com就可以，这样既能够摆脱无穷尽的appspot二级域名还可以成功让国内用户访问到构建在GAE上的网站。
示例网站：
Google App Engine、Python 2.7、High Relication、Webapp2......