wsgi-accelerator 0.1.0

特性

• 缓存读密集型URL

• ETag支持

• 基于标签的精细缓存失效

• 基于时间的缓存失效（类似于Cache-Control）

• 可插拔的缓存存储 - 包括内存和Redis存储

• 非常简单且可修改 - 测试代码除外，少于200行代码

• MIT许可

入门

目前，wsgi-accelerator由于仍在进行调整，因此无法通过PyPI获取。但之后它将像正常的 pip install 一样。

安装后，您可以使用默认的内存存储启用它，如下所示

from accelerator import WSGIAccelerator

def app(environ, start_response):
    response_body = 'Hello World'
    status = '200 OK'

    response_headers = [
        ('Content-Type', 'text/plain'),
        ('Content-Length', str(len(response_body)))
    ]

    environ['accelerator.cache_for'] = 5 # Cache for five seconds
    environ['accelerator.tags'] = ['foo', 'bar']
    start_response(status, response_headers)
    return [response_body]

app = WSGIAccelerator(app)

# To invalidate the response generated by the WSGI app above, just call:
app.invalidate_tag(['foo'])

# This will trigger invalidation of that URL path + query since it was
# tagged when the response was generated.

请注意，内存存储不适合生产使用。它仅用于测试和作为正确参考实现。

也许不用说，但通过wsgi-accelerator缓存的全部响应都不能包含任何用户特定数据。

使用案例

想象您有一个拥有众多用户和社交功能的流行网站。拥有一个流行的网站也意味着您需要处理大量的流量，这意味着硬件和带宽方面的巨大成本。造成这种情况的一个原因通常是您通常需要从服务器上为每个HTTP请求提供新鲜内容，因为这可能会发生变化。

其他一些也是高流量但本质更静态的网站，例如维基百科或报纸，通常会选择Varnish这样的HTTP缓存来帮助解决这个问题。这效果非常好，并且可以显著减轻CPU负载。值得注意的是，只有当读取操作多于昂贵的写入操作时，缓存才能发挥其全部潜力。

但对于一个拥有更多用户生成内容的动态网站，在HTTP级别上缓存通常更为复杂，甚至可能无法实现。因此，大多数缓存最终都在应用程序的“业务/域逻辑”级别上实现。这种缓存确实在节省资源方面有很大帮助，但仍然需要每个HTTP请求触发应用深层的代码路径，导致CPU周期被浪费。

解决这个问题的一个好方法是为易变用户生成内容启用HTTP级别的缓存。这就是wsgi-accelerator发挥作用的地方：）

一个例子

在这个虚拟网站上，我们有一个类似这样的用户资料页面

其中每个黄色气泡都代表构成最终页面的数据源。

如果我们通过传统方式缓存这个页面，只要用户进行任何改变上述数据的操作，页面就会过时。显然这不是最佳方案。但好处是我们知道那些动作何时会发生。利用这些信息，我们可以确保在用户触发任何这些事件时立即使该页面的缓存条目无效。因此，下次加载该页面时，它将以正常方式击中应用程序，渲染并缓存新的更改数据。这种细粒度触发缓存中内容失效的概念，使您能够缓存整个HTTP响应，而不会存在提供过时数据的风险。

由于这是一个普通的WSGI中间件，除了可能的备份缓存存储之外，不需要任何额外的服务器/代理。

许可协议

开源软件，采用MIT许可协议（详细信息请参阅LICENSE文件）。

如果您觉得这个想法和库很有用，请告诉我。我很乐意听您的故事和用例。

Carl Byström (@cgbystrom)