wsgi-accelerator 0.1.0

功能

• 缓存读取重URL
• ETag支持
• 细粒度、基于标记的缓存失效
• 基于时间的缓存失效（ALA缓存控制）
• 可插拔缓存存储-包括内存和redis存储
• 超级简单且可破解-不包括测试的位置小于200
• 麻省理工学院授权

开始

现在wsgi加速器无法通过pypi使用，因为它仍在接受调整。 但之后将是正常的pip install场景。

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

fromacceleratorimportWSGIAcceleratordefapp(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 secondsenviron['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加速器缓存的所有响应都不能包含特定于用户的数据。

用例

假设你有一个很受欢迎的网站，有很多用户和社交功能。拥有一个受欢迎的网站也意味着你的流量很大， 意味着硬件和带宽方面的巨大成本。其中一个原因是，您通常需要在每个http上提供新的内容 从那以后你的服务器可能已经改变了。

其他网站，如维基百科或报纸，流量也很高，但本质上比较静态，通常会使用类似varnish的http缓存来帮助解决这个问题。 这工作得非常好，可以大大减少cpu负载。 另外值得注意的是，缓存只有在读出大量昂贵的写操作时才意识到它的全部潜力。

但是对于一个包含更多用户生成内容的动态站点，缓存通常要复杂得多，如果在http级别上不是不可能的话。 因此，大多数缓存最终发生在应用程序内部的“业务/域逻辑”级别。这样的缓存确实有很大帮助 为了节省资源，但仍然需要每个http请求触发应用程序深层的代码路径，从而导致cpu周期消耗。

解决这个问题的一个好办法是启用易失性、用户生成内容的http级缓存。 这就是wsgi加速器的作用：）

示例

在这个虚构的站点上，我们有与此类似的用户配置文件页：

其中每个黄色气泡表示构成最后一页的数据源。

如果我们要通过传统方式缓存此页，那么一旦用户执行了更改上述任何一项的操作，它就会过时。 显然不太理想。 但好的是，我们知道这些行动什么时候能发生，什么时候会发生。通过使用这些信息，我们可以确保 一旦用户触发这些事件中的任何一个，该页的缓存条目。 因此，下一次加载该页时，它将像正常情况一样命中应用程序，并使用新更改的数据进行呈现和缓存。 这种具有触发缓存中内容失效的细粒度方法的概念使您能够缓存整个http响应，而不必冒提供陈旧数据的风险。

<> p>并且这是一个普通的WSGi中间件，除了可能的后备缓存存储之外，不需要额外的服务器/代理。