Ale*_*rdt 21 html google-app-engine caching
我编写了一个Google App Engine应用程序,以编程方式生成一堆HTML代码,这些代码对于登录我系统的每个用户来说实际上是相同的输出,我知道当代码投入生产时这将是无效的.所以,我试图找出缓存生成的页面的最佳方法.
最可能的选择是生成页面并将它们写入数据库,然后检查给定页面的数据库放置操作的时间与上次更新代码的时间.然后,如果代码比最后一次放入数据库(对于特定的HTML请求)更新,则将生成并提供新的HTML,并将其缓存到数据库.如果代码比上次放入数据库的时间要早,那么我将直接从数据库中获取HTML并为其提供服务(因此避免了生成HTML的所有CPU浪费).我不仅希望最小化加载时间,还要尽量减少CPU使用率.
但是,我遇到的一个问题是,我无法弄清楚如何以编程方式检查上传到应用引擎的代码版本何时更新.
我对这种方法的任何建议或其他缓存生成的html方法持开放态度.
请注意,虽然memcache可以在这种情况下提供帮助,但我认为它不是最终的解决方案,因为我真的只需要在代码更新时重新生成html(而不是每次memcache到期时).
按速度顺序:
您的缓存解决方案应考虑到这一点.基本上,我可能会建议使用memcache.在大多数情况下,它比访问数据存储更快,当您生成大块HTML时,缓存的主要好处之一是您可能不必因访问数据而导致I/O损失.商店.如果使用数据存储进行缓存,则仍会产生I/O损失.除非你有一个非常复杂的页面,否则重新生成所有东西和从数据存储中的缓存html拉取之间的区别可能相当小.从memcache中获取一堆非常快的缓存命中并且每隔一段时间进行一次完全重新生成可能比每次调用数据存储更好.当你更新时,没有什么可以阻止你在memcache中使缓存的HTML失效,如果你的流量足够高,可以保证它,你总是可以做一个多级缓存系统.
但是,我主要担心的是这是不成熟的优化.如果您还没有流量,请将缓存保持在最低限度.App Engine提供了一组非常方便的性能分析工具,您应该使用这些工具来识别至少几个QPS流量之后的瓶颈.
无论何时进行性能优化,首先要测量!许多性能"优化"要么比原来慢,要么完全相同,要么具有负面的用户体验特征(如陈旧数据).在确定必须之前不要进行优化.
| 归档时间： |
|
| 查看次数： |
5942 次 |
| 最近记录： |