在 Django 1.3 alpha 1 中,内置 Web 服务器是否比以前更积极地缓存页面(或数据库结果)?

发布于 2024-10-06 21:36:21 字数 356 浏览 3 评论 0原文

我正在使用 Django 版本 1.3 alpha 1 (SVN-14750) 构建 Django 网站。

我有几个页面显示数据,并允许我编辑该数据。但是,我似乎必须重新启动内置的 Django Web 服务器才能看到更新的数据。

我不记得以前遇到过这个问题:通常在浏览器中刷新 CTRL + F5 就可以解决这个问题。显然,在开发过程中这是非常烦人的行为,看到最新数据加载速度变慢比立即看到过时数据加载要好。

我使用的是禁用缓存的 Firefox(about:config, network.http.use-cache=False),因此我相当确定问题出在 Django 上。

I’m using Django version 1.3 alpha 1 (SVN-14750) to build a Django site.

I’ve got a couple of pages which display data, and allow me to edit that data. However, I seem to have to restart the built-in Django web server to see the updated data.

I don’t remember having this problem before: usually a CTRL + F5 refresh in the browser would do it. Obviously, it’s quite annoying behaviour during development, seeing up-to-date data load slower is preferable to seeing out-of-date data load instantly.

I’m using Firefox with the cache disabled (about:config, network.http.use-cache=False), so I’m reasonably sure the issue is with Django.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

尘曦 2024-10-13 21:36:21

Web 服务器本身不进行缓存。由应用程序本身决定(服务器端)缓存如何工作。就 Django 而言,有许多启用缓存的选项。

不过,高级的是 Django 看到对 URL 的请求,生成响应中的 html 字符串,并将该字符串存储在内存中(或数据库 - 取决于您设置的缓存后端)。下次对同一 URL 发出请求时,Django 将检查该响应是否存在于缓存中,如果存在,则返回该字符串。如果没有,则重复该过程。

提供 @vary_on 装饰器背后的想法是,您可以更改查找键以在缓存中查找响应。如果你改变(用户,网址)。该算法是这样的:

1. request /users/3/Josh
2. key = str(user) + str(url)
3. response = get_from_cache(key)
4. if response is None: response = view_function()
5. save_to_cache(key, response)
6. return response 

Web 服务器没有输入到这种类型的缓存中。

另一种类型的缓存是客户端。这是 Web 服务器被配置为返回特定类型资源(如静态内容(javascript、图像等))的某些标头的地方。然后,浏览器可以分析这些标头,并决定请求内容,或使用客户端存储的内容。然而,这通常不适用于动态内容。

Web servers themselves don't do caching. It is up to the application itself to decide how (server-side) caching works. In Django's case, there are a number of options for enabling caching.

The high level though, is that Django sees a request for an URL, generates the html string in response, and stores that string in memory (or a database - depending on the cache backend you set). The next time a request comes through for that same URL, Django will check to see if that response lives in the cache, and if it does, will return that string. If it doesn't, the process repeats.

The idea behind providing @vary_on decorators, is that you change the lookup keys for finding a response in the cache. If you vary_on(user, url). the algorithm goes something like this:

1. request /users/3/Josh
2. key = str(user) + str(url)
3. response = get_from_cache(key)
4. if response is None: response = view_function()
5. save_to_cache(key, response)
6. return response 

The web server has no input into this type of caching.

The other type of caching is client side. This is where the web server is configured to return certain headers for specific types of resources like static content (javascript, images etc). The browser can then analyze those headers, and decide to request the content, or to use the content stored client side. This generally doesn't apply to dynamic content however.

执笔绘流年 2024-10-13 21:36:21

啊——我仍然启用了一些缓存中间件。从 settings.py 中的 MIDDLEWARE_CLASSES 设置中删除以下内容修复了该问题。

'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',

(从问题和这个答案中可以明显看出,我不太了解缓存、Django 或其他方式。)

Ah — I still had some cache middleware enabled. Removing the following from my MIDDLEWARE_CLASSES setting in settings.py fixed it.

'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',

(As is probably evident from the question and this answer, I don’t understand caching, Django or otherwise, very well.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文