1
aveline 2014-07-05 14:41:19 +08:00
是阻塞的 ... 所以这个功能很鸡肋。
是想实现 Squid 里的 Collapsed Forwarding 功能么? |
2
Livid MOD OP @aveline 在测试到底是怎样的。
这里有篇博客说和 Squid 的类似: https://blog.feuvan.net/2013/07/12/10135-nginx-proxy-cache-lock.html |
3
lsylsy2 2014-07-05 14:46:59 +08:00
一直觉着Nginx的缓存做的不好,只用来做负载均衡,缓存还是交给Varnish和Squid
|
4
alex321 2014-07-05 15:00:20 +08:00
我在网上照抄了一堆做了基于 sslstart 的 google 反向代理给身边的小伙伴们使用,设置了 cache 2g,可能是访问量很小,目前还没遇到什么症状,也不知道这个缓存的价值如何。
|
5
aveline 2014-07-05 15:07:01 +08:00
在本地重新测试了一下,proxy_cache_lock 打开的时候,另一个同样 cache key 的请求在到达 proxy_cache_lock_timeout 之前是不会发起的。
|
6
Livid MOD OP |
8
Livid MOD OP @aveline 关于 proxy_cache_lock 的问题,今天又研究了一下。总算是找到 Nginx.org 官方的 Maxim Dounin 的答复了:
https://www.ruby-forum.com/topic/5010940 Hello! On Mon, Jun 30, 2014 at 11:10:52PM -0400, Paul Schlie wrote: > being seemingly why proxy_cache_lock was introduced, as you initially suggested. Again: responses are not guaranteed to be the same, and unless you are using cache (and hence proxy_cache_key and various header checks to ensure responses are at least interchangeable), the only thing you can do is to proxy requests one by one. If you are using cache, then there is proxy_cache_key to identify a resource requested, and proxy_cache_lock to prevent multiple parallel requests to populate the same cache node (and "proxy_cache_use_stale updating" to prevent multiple requests when updating a cache node). In theory, cache code can be improved (compared to what we currently have) to introduce sending of a response being loaded into a cache to multiple clients. I.e., stop waiting for a cache lock once we've got the response headers, and stream the response body being load to all clients waited for it. This should/can help when loading large files into a cache, when waiting with proxy_cache_lock for a complete response isn't cheap. In practice, introducing such a code isn't cheap either, and it's not about using other names for temporary files. -- Maxim Dounin http://nginx.org/ 好想悬赏找人做这个功能。 |
9
Livid MOD OP 嗯,必须找公司申请资源把这个功能做了。
|