So for the time being should I update the English wiki to show that
0.6.30 is the latest stable release. It seems this would be best for
newcomers to understand rather than now it says 0.5.35 is latest. Yet
it may also be confusing for some to see 0.6.30 (at least until 0.7 is
branched) is also the latest dev release. Any way just let me know what
you think is best and I'll update it or leave it alone.
The new cache feature in 0.7 sounds interesting - is there any where I
can learn more about what this is for and its benefits?
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
on 04.05.2008 18:44
on 04.05.2008 19:31
On Sun, 2008-05-04 at 09:34 -0700, Rt Ibmer wrote: > So for the time being should I update the English wiki to show that > 0.6.30 is the latest stable release. It seems this would be best for > newcomers to understand rather than now it says 0.5.35 is latest. Yet > it may also be confusing for some to see 0.6.30 (at least until 0.7 is > branched) is also the latest dev release. Any way just let me know > what you think is best and I'll update it or leave it alone. Go ahead and mark 0.5.x as "legacy" and 0.6.x as "stable" with a section mentioning that a 0.7.x "development" branch will soon be started. Thanks for helping! Cliff
on 04.05.2008 20:38
On Sun, May 04, 2008 at 09:34:59AM -0700, Rt Ibmer wrote: > So for the time being should I update the English wiki to show that 0.6.30 is the latest stable release. It seems this would be best for newcomers to understand rather than now it says 0.5.35 is latest. Yet it may also be confusing for some to see 0.6.30 (at least until 0.7 is branched) is also the latest dev release. Any way just let me know what you think is best and I'll update it or leave it alone. Please, do as Cliff has suggested. > The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits? In first release cache will cache upstream responses on disk.
on 04.05.2008 23:40
On 5/4/08, Igor Sysoev <is@rambler-co.ru> wrote: > > The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits? > > In first release cache will cache upstream responses on disk. Is that more or less like this? http://hostingfu.com/article/nginx-and-mirror-demand
on 05.05.2008 07:29
On Sun, May 04, 2008 at 02:33:01PM -0700, mike wrote: > On 5/4/08, Igor Sysoev <is@rambler-co.ru> wrote: > > > > The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits? > > > > In first release cache will cache upstream responses on disk. > > Is that more or less like this? > http://hostingfu.com/article/nginx-and-mirror-demand No, cache takes into account expire time to refresh responses and inactivity time to delete responses from cache.
on 05.05.2008 10:24
On 5/4/08, Igor Sysoev <is@rambler-co.ru> wrote: > > Is that more or less like this? > > http://hostingfu.com/article/nginx-and-mirror-demand > > No, cache takes into account expire time to refresh responses and > inactivity time to delete responses from cache. So basically that URL, with an LRU cache mechanism and expiry support?
on 05.05.2008 10:39
On Mon, May 05, 2008 at 01:11:54AM -0700, mike wrote: > On 5/4/08, Igor Sysoev <is@rambler-co.ru> wrote: > > > > Is that more or less like this? > > > http://hostingfu.com/article/nginx-and-mirror-demand > > > > No, cache takes into account expire time to refresh responses and > > inactivity time to delete responses from cache. > > So basically that URL, with an LRU cache mechanism and expiry support? No, requests are not directly mapped to filesystem. Instead md5 is taken from the proxied URL and this hash is used to find response in cache. Besides, the cached response has full header: for example, 404 response may be cached. Also the response may be cached only if it was requested no less than, e.g., 2 times for some time.
on 05.05.2008 10:50
Igor - this sounds brilliant ! This is *exactly* what we need in my business to cache a large number of dynamically generated images that are at the moment being stored in HUGE monolithic directories. I look forward to trying this. Dave
on 05.05.2008 10:55
On Mon, May 05, 2008 at 06:43:44PM +1000, Dave Cheney wrote: > Igor - this sounds brilliant ! > > This is *exactly* what we need in my business to cache a large number > of dynamically generated images that are at the moment being stored in > HUGE monolithic directories. > > I look forward to trying this. I can give the current snapshot. It ignores the backend "Cache-Control", "Expires", etc. headers, so this is the main reason why I still did not release it.
on 05.05.2008 11:45
That could be ok, we issue very long ttls on those urls because we expire them by a version number embedded in the itself. The main value for would be in hashing the cache store. Cheers Dave