Re: 2.1 plans
+1. This is a very good idea for optimizing RAM utilization. --Michael On Jan 8, 2009, at 11:25 AM, Jeff Anderson wrote: > Thanks for the response. > > I think inline page compression would be great too. Store gzipped > objects in the persistent cache and unzip if uncompressed objects are > requested. > > > > > On Jan 8, 2009, at 10:54 AM, Per Buer wrote: > >> Jeff Anderson wrote: >>> I'd like to see individual object request statistics and a method to >>> prefetch objects from the backend that are most frequently >>> requested. >>> Perhaps also a way to prioritize objects into cache tiers based on >>> frequency of requests. So, for example, highly requested objects >>> are >>> maintained in RAM and less frequently requested objects are cached >>> to >>> disk. >> >> Your operating system already does this today with Varnish. Squid >> tries >> to maintain a two tier cache hierarchy without success. >> >>> If persistent storage is on its way maybe a method to assign >>> priority to large disk cache volumes versus memory regions. >> >> Noted. >> >>> It might be nice to have a distributed and/or tiered cache model >>> where a single >>> master has a very large cache and potentially very long grace >>> ability >>> where objects can exist even if stale. That master in turn could >>> host >>> frontend caches that communicate efficiently to the master cache >>> and >>> also have a tiered internal object priority. >> >> I believe most of this can be achieved today. Stale objects will >> hopefully reach the 2.0 series before the 2.1 revolutions - at least >> as >> a patch, I hope. >> >>> >>> Thanks, >>> --Jeff >>> >>> >>> On Jan 8, 2009, at 2:29 AM, Tollef Fog Heen wrote: >>> Hi, a short while before Christmas, I wrote up a small document pointing to what I would like to get into 2.1 and when I'd like milestones to happen. This is a suggestion, I'm open to ideas and comments on both feature set as well as if my guesstimates for dates is completely off: Varnish 2.1 release plan The theme for Varnish 2.1 is "scalability", particularly trying to address the needs of sites like finn.no which has a lot of objects and where priming the cache takes a long time, leading to long periods of higher load on the backend servers. The main feature is persistent storage, see http://varnish.projects.linpro.no/wiki/ ArchitecturePersistentStorage for design notes. Another important scalability feature is a new lockless hash algorithm which scales much better than the current one. Poul-Henning already has an implementation of this in the tree, but it's still fresh. Minor features which would be nice to get in are: * Web UI, showing pretty graphs as well as allowing easy configuration of a cluster of Varnish machines. * Expiry randomisation. This reduces the "lemmings" effect where you end up with a many objects with almost the same TTL (typically on startup) which then expire at the same time. The feature will allow you to set the TTL to plus/minus X %. * Dynamic, user-defined counters that can be read and written from VCL * Forced purges, where a thread walks the list of purged objects and removes them. The schedule Alphas: - 2009-01-15: New hash algorithm working - 2009-02-15: Web UI - 2009-03-15: Persistent storage Beta: - 2009-04-01: Feature complete Release - 2009-05-20: Release candidate - 2009-05-01: No release critical bugs left - 2009-05-10: Release -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc >>> >>> --Jeff >>> j...@funnyordie.com >>> >>> >>> >>> ___ >>> varnish-misc mailing list >>> varnish-misc@projects.linpro.no >>> http://projects.linpro.no/mailman/listinfo/varnish-misc >> >> >> -- >> Per Buer - Leder Infrastruktur og Drift - Redpill Linpro >> Telefon: 21 54 41 21 - Mobil: 958 39 117 >> http://linpro.no/ | http://redpill.se/ >> >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > --Jeff > j...@funnyordie.com > > > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.1 plans
Thanks for the response. I think inline page compression would be great too. Store gzipped objects in the persistent cache and unzip if uncompressed objects are requested. On Jan 8, 2009, at 10:54 AM, Per Buer wrote: > Jeff Anderson wrote: >> I'd like to see individual object request statistics and a method to >> prefetch objects from the backend that are most frequently requested. >> Perhaps also a way to prioritize objects into cache tiers based on >> frequency of requests. So, for example, highly requested objects are >> maintained in RAM and less frequently requested objects are cached to >> disk. > > Your operating system already does this today with Varnish. Squid > tries > to maintain a two tier cache hierarchy without success. > >> If persistent storage is on its way maybe a method to assign >> priority to large disk cache volumes versus memory regions. > > Noted. > >> It might be nice to have a distributed and/or tiered cache model >> where a single >> master has a very large cache and potentially very long grace ability >> where objects can exist even if stale. That master in turn could >> host >> frontend caches that communicate efficiently to the master cache and >> also have a tiered internal object priority. > > I believe most of this can be achieved today. Stale objects will > hopefully reach the 2.0 series before the 2.1 revolutions - at least > as > a patch, I hope. > >> >> Thanks, >> --Jeff >> >> >> On Jan 8, 2009, at 2:29 AM, Tollef Fog Heen wrote: >> >>> Hi, >>> >>> a short while before Christmas, I wrote up a small document pointing >>> to >>> what I would like to get into 2.1 and when I'd like milestones to >>> happen. This is a suggestion, I'm open to ideas and comments on >>> both >>> feature set as well as if my guesstimates for dates is completely >>> off: >>> >>> Varnish 2.1 release plan >>> >>> The theme for Varnish 2.1 is "scalability", particularly trying to >>> address the needs of sites like finn.no which has a lot of objects >>> and >>> where priming the cache takes a long time, leading to long periods >>> of >>> higher load on the backend servers. >>> >>> The main feature is persistent storage, see >>> http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage >>> for design notes. Another important scalability feature is a new >>> lockless hash algorithm which scales much better than the current >>> one. Poul-Henning already has an implementation of this in the >>> tree, >>> but it's still fresh. >>> >>> Minor features which would be nice to get in are: >>> >>> * Web UI, showing pretty graphs as well as allowing easy >>> configuration >>> of a cluster of Varnish machines. >>> >>> * Expiry randomisation. This reduces the "lemmings" effect where >>> you >>> end up with a many objects with almost the same TTL (typically on >>> startup) which then expire at the same time. The feature will allow >>> you to set the TTL to plus/minus X %. >>> >>> * Dynamic, user-defined counters that can be read and written from >>> VCL >>> >>> * Forced purges, where a thread walks the list of purged objects and >>> removes them. >>> >>> The schedule >>> >>> >>> Alphas: >>> - 2009-01-15: New hash algorithm working >>> - 2009-02-15: Web UI >>> - 2009-03-15: Persistent storage >>> Beta: >>> - 2009-04-01: Feature complete >>> Release >>> - 2009-05-20: Release candidate >>> - 2009-05-01: No release critical bugs left >>> - 2009-05-10: Release >>> >>> -- >>> Tollef Fog Heen >>> Redpill Linpro -- Changing the game! >>> t: +47 21 54 41 73 >>> ___ >>> varnish-misc mailing list >>> varnish-misc@projects.linpro.no >>> http://projects.linpro.no/mailman/listinfo/varnish-misc >> >> --Jeff >> j...@funnyordie.com >> >> >> >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > > -- > Per Buer - Leder Infrastruktur og Drift - Redpill Linpro > Telefon: 21 54 41 21 - Mobil: 958 39 117 > http://linpro.no/ | http://redpill.se/ > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc --Jeff j...@funnyordie.com ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.1 plans
Hi, Tollef Fog Heen wrote: > Hi, > > a short while before Christmas, I wrote up a small document pointing to > what I would like to get into 2.1 and when I'd like milestones to > happen. This is a suggestion, I'm open to ideas and comments on both > feature set as well as if my guesstimates for dates is completely off: > > Varnish 2.1 release plan > (..) As the money man in the project I would like to say that if anybody misses anything on the feature list we are happy to talk to sponsors about it. Send me or varn...@linpro.no an email and we'll discuss it. Your feature might not go into the mainline right away but we'll be happy to support a patched version of varnish until we are able to put the patch into a proper release. Regards Per. -- http://linpro.no/ | http://redpill.se/ signature.asc Description: OpenPGP digital signature ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.1 plans
Jeff Anderson wrote: > I'd like to see individual object request statistics and a method to > prefetch objects from the backend that are most frequently requested. > Perhaps also a way to prioritize objects into cache tiers based on > frequency of requests. So, for example, highly requested objects are > maintained in RAM and less frequently requested objects are cached to > disk. Your operating system already does this today with Varnish. Squid tries to maintain a two tier cache hierarchy without success. > If persistent storage is on its way maybe a method to assign > priority to large disk cache volumes versus memory regions. Noted. > It might be nice to have a distributed and/or tiered cache model where a > single > master has a very large cache and potentially very long grace ability > where objects can exist even if stale. That master in turn could host > frontend caches that communicate efficiently to the master cache and > also have a tiered internal object priority. I believe most of this can be achieved today. Stale objects will hopefully reach the 2.0 series before the 2.1 revolutions - at least as a patch, I hope. > > Thanks, > --Jeff > > > On Jan 8, 2009, at 2:29 AM, Tollef Fog Heen wrote: > >> Hi, >> >> a short while before Christmas, I wrote up a small document pointing >> to >> what I would like to get into 2.1 and when I'd like milestones to >> happen. This is a suggestion, I'm open to ideas and comments on both >> feature set as well as if my guesstimates for dates is completely off: >> >> Varnish 2.1 release plan >> >> The theme for Varnish 2.1 is "scalability", particularly trying to >> address the needs of sites like finn.no which has a lot of objects and >> where priming the cache takes a long time, leading to long periods of >> higher load on the backend servers. >> >> The main feature is persistent storage, see >> http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage >> for design notes. Another important scalability feature is a new >> lockless hash algorithm which scales much better than the current >> one. Poul-Henning already has an implementation of this in the tree, >> but it's still fresh. >> >> Minor features which would be nice to get in are: >> >> * Web UI, showing pretty graphs as well as allowing easy configuration >> of a cluster of Varnish machines. >> >> * Expiry randomisation. This reduces the "lemmings" effect where you >> end up with a many objects with almost the same TTL (typically on >> startup) which then expire at the same time. The feature will allow >> you to set the TTL to plus/minus X %. >> >> * Dynamic, user-defined counters that can be read and written from VCL >> >> * Forced purges, where a thread walks the list of purged objects and >> removes them. >> >> The schedule >> >> >> Alphas: >> - 2009-01-15: New hash algorithm working >> - 2009-02-15: Web UI >> - 2009-03-15: Persistent storage >> Beta: >> - 2009-04-01: Feature complete >> Release >> - 2009-05-20: Release candidate >> - 2009-05-01: No release critical bugs left >> - 2009-05-10: Release >> >> -- >> Tollef Fog Heen >> Redpill Linpro -- Changing the game! >> t: +47 21 54 41 73 >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > --Jeff > j...@funnyordie.com > > > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -- Per Buer - Leder Infrastruktur og Drift - Redpill Linpro Telefon: 21 54 41 21 - Mobil: 958 39 117 http://linpro.no/ | http://redpill.se/ signature.asc Description: OpenPGP digital signature ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.0.3 planning
This is a very strange comment. If Varnish requires a particular sequence, it should implement its own. If it requires particular statistical properties, it should test for those, not test for a specific sequence. Tim On Jan 8, 2009, at 2:12 AM, Tollef Fog Heen wrote: > > r3367 | phk | 2008-11-10 10:37:21 +0100 (ma., 10 nov. 2008) | 14 lines > > Add a toplevel word which examines the sequence returned by > srandom(1) and stops the test if we do not get the same sequence > as we expect. > > The Open Group does not define which deterministic sequence srandom(1) > should result in, on that it be deterministic, but I have high hopes > in the general sanity and expect that UNIX people across the board > have realized that for portability the same sequence should be > returned on all platforms. > > At the very least FreeBSD and Linux/GLIBC, as seen on > projects.linpro.no, > agree. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.1 plans
I'd like to see individual object request statistics and a method to prefetch objects from the backend that are most frequently requested. Perhaps also a way to prioritize objects into cache tiers based on frequency of requests. So, for example, highly requested objects are maintained in RAM and less frequently requested objects are cached to disk. If persistent storage is on its way maybe a method to assign priority to large disk cache volumes versus memory regions. It might be nice to have a distributed and/or tiered cache model where a single master has a very large cache and potentially very long grace ability where objects can exist even if stale. That master in turn could host frontend caches that communicate efficiently to the master cache and also have a tiered internal object priority. Thanks, --Jeff On Jan 8, 2009, at 2:29 AM, Tollef Fog Heen wrote: > > Hi, > > a short while before Christmas, I wrote up a small document pointing > to > what I would like to get into 2.1 and when I'd like milestones to > happen. This is a suggestion, I'm open to ideas and comments on both > feature set as well as if my guesstimates for dates is completely off: > > Varnish 2.1 release plan > > The theme for Varnish 2.1 is "scalability", particularly trying to > address the needs of sites like finn.no which has a lot of objects and > where priming the cache takes a long time, leading to long periods of > higher load on the backend servers. > > The main feature is persistent storage, see > http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage > for design notes. Another important scalability feature is a new > lockless hash algorithm which scales much better than the current > one. Poul-Henning already has an implementation of this in the tree, > but it's still fresh. > > Minor features which would be nice to get in are: > > * Web UI, showing pretty graphs as well as allowing easy configuration > of a cluster of Varnish machines. > > * Expiry randomisation. This reduces the "lemmings" effect where you > end up with a many objects with almost the same TTL (typically on > startup) which then expire at the same time. The feature will allow > you to set the TTL to plus/minus X %. > > * Dynamic, user-defined counters that can be read and written from VCL > > * Forced purges, where a thread walks the list of purged objects and > removes them. > > The schedule > > > Alphas: > - 2009-01-15: New hash algorithm working > - 2009-02-15: Web UI > - 2009-03-15: Persistent storage > Beta: > - 2009-04-01: Feature complete > Release > - 2009-05-20: Release candidate > - 2009-05-01: No release critical bugs left > - 2009-05-10: Release > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc --Jeff j...@funnyordie.com ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: 2.1 plans
What about CARP-like cache routing (i.e., where multiple cache servers themselves are hash buckets)? This would go a LONG way towards scalability. --Michael On Jan 8, 2009, at 2:29 AM, Tollef Fog Heen wrote: > > Hi, > > a short while before Christmas, I wrote up a small document pointing > to > what I would like to get into 2.1 and when I'd like milestones to > happen. This is a suggestion, I'm open to ideas and comments on both > feature set as well as if my guesstimates for dates is completely off: > > Varnish 2.1 release plan > > The theme for Varnish 2.1 is "scalability", particularly trying to > address the needs of sites like finn.no which has a lot of objects and > where priming the cache takes a long time, leading to long periods of > higher load on the backend servers. > > The main feature is persistent storage, see > http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage > for design notes. Another important scalability feature is a new > lockless hash algorithm which scales much better than the current > one. Poul-Henning already has an implementation of this in the tree, > but it's still fresh. > > Minor features which would be nice to get in are: > > * Web UI, showing pretty graphs as well as allowing easy configuration > of a cluster of Varnish machines. > > * Expiry randomisation. This reduces the "lemmings" effect where you > end up with a many objects with almost the same TTL (typically on > startup) which then expire at the same time. The feature will allow > you to set the TTL to plus/minus X %. > > * Dynamic, user-defined counters that can be read and written from VCL > > * Forced purges, where a thread walks the list of purged objects and > removes them. > > The schedule > > > Alphas: > - 2009-01-15: New hash algorithm working > - 2009-02-15: Web UI > - 2009-03-15: Persistent storage > Beta: > - 2009-04-01: Feature complete > Release > - 2009-05-20: Release candidate > - 2009-05-01: No release critical bugs left > - 2009-05-10: Release > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
RE: 2.1 plans
Great news ! What about more ESI features (ie : cookie support), backend revalidation with conditional GETs or streaming fetches (http://varnish.projects.linpro.no/wiki/PostTwoShoppingList) ? Jean-François > -Message d'origine- > De : varnish-misc-boun...@projects.linpro.no > [mailto:varnish-misc-boun...@projects.linpro.no] De la part > de Tollef Fog Heen > Envoyé : jeudi 8 janvier 2009 11:30 > À : varnish-misc@projects.linpro.no > Objet : 2.1 plans > > > Hi, > > a short while before Christmas, I wrote up a small document > pointing to > what I would like to get into 2.1 and when I'd like milestones to > happen. This is a suggestion, I'm open to ideas and comments on both > feature set as well as if my guesstimates for dates is completely off: > > Varnish 2.1 release plan > > The theme for Varnish 2.1 is "scalability", particularly trying to > address the needs of sites like finn.no which has a lot of objects and > where priming the cache takes a long time, leading to long periods of > higher load on the backend servers. > > The main feature is persistent storage, see > http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage > for design notes. Another important scalability feature is a new > lockless hash algorithm which scales much better than the current > one. Poul-Henning already has an implementation of this in the tree, > but it's still fresh. > > Minor features which would be nice to get in are: > > * Web UI, showing pretty graphs as well as allowing easy configuration > of a cluster of Varnish machines. > > * Expiry randomisation. This reduces the "lemmings" effect where you > end up with a many objects with almost the same TTL (typically on > startup) which then expire at the same time. The feature will allow > you to set the TTL to plus/minus X %. > > * Dynamic, user-defined counters that can be read and written from VCL > > * Forced purges, where a thread walks the list of purged objects and > removes them. > > The schedule > > > Alphas: > - 2009-01-15: New hash algorithm working > - 2009-02-15: Web UI > - 2009-03-15: Persistent storage > Beta: > - 2009-04-01: Feature complete > Release > - 2009-05-20: Release candidate > - 2009-05-01: No release critical bugs left > - 2009-05-10: Release > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
2.1 plans
Hi, a short while before Christmas, I wrote up a small document pointing to what I would like to get into 2.1 and when I'd like milestones to happen. This is a suggestion, I'm open to ideas and comments on both feature set as well as if my guesstimates for dates is completely off: Varnish 2.1 release plan The theme for Varnish 2.1 is "scalability", particularly trying to address the needs of sites like finn.no which has a lot of objects and where priming the cache takes a long time, leading to long periods of higher load on the backend servers. The main feature is persistent storage, see http://varnish.projects.linpro.no/wiki/ArchitecturePersistentStorage for design notes. Another important scalability feature is a new lockless hash algorithm which scales much better than the current one. Poul-Henning already has an implementation of this in the tree, but it's still fresh. Minor features which would be nice to get in are: * Web UI, showing pretty graphs as well as allowing easy configuration of a cluster of Varnish machines. * Expiry randomisation. This reduces the "lemmings" effect where you end up with a many objects with almost the same TTL (typically on startup) which then expire at the same time. The feature will allow you to set the TTL to plus/minus X %. * Dynamic, user-defined counters that can be read and written from VCL * Forced purges, where a thread walks the list of purged objects and removes them. The schedule Alphas: - 2009-01-15: New hash algorithm working - 2009-02-15: Web UI - 2009-03-15: Persistent storage Beta: - 2009-04-01: Feature complete Release - 2009-05-20: Release candidate - 2009-05-01: No release critical bugs left - 2009-05-10: Release -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
2.0.3 planning
Hi, I'm evaluating what changes that should go into 2.0.3 and have come up with the following list: r3433 | phk | 2008-11-25 09:37:34 +0100 (ti., 25 nov. 2008) | 6 lines When we receive an If-Modified-Since on an ESI object, do not process the conditional for the child object and pretend to send a 304 reply for them, if we have decided to deliver the main object. Fixes #386 r3361 | tfheen | 2008-11-06 12:46:31 +0100 (to., 06 nov. 2008) | 7 lines Fix up $N vs \N in man page The VCL man page documented the capturing parentheses as using $N rather than \N which is actually used. Fixes #359 r3362 | tfheen | 2008-11-06 12:57:05 +0100 (to., 06 nov. 2008) | 4 lines Document the size parameter to -s malloc Fixes #362 r3366 | phk | 2008-11-10 10:29:52 +0100 (ma., 10 nov. 2008) | 12 lines Add a debug CLI command to seed random(3). This is a lot less useful than it could have been, as the Open Group only mandates that: Like rand(), random() shall produce by default a sequence of numbers that can be duplicated by calling srandom() with 1 as the seed. But crucially leaves out *which* sequence of numbers. r3367 | phk | 2008-11-10 10:37:21 +0100 (ma., 10 nov. 2008) | 14 lines Add a toplevel word which examines the sequence returned by srandom(1) and stops the test if we do not get the same sequence as we expect. The Open Group does not define which deterministic sequence srandom(1) should result in, on that it be deterministic, but I have high hopes in the general sanity and expect that UNIX people across the board have realized that for portability the same sequence should be returned on all platforms. At the very least FreeBSD and Linux/GLIBC, as seen on projects.linpro.no, agree. r3368 | phk | 2008-11-10 10:40:39 +0100 (ma., 10 nov. 2008) | 7 lines Add a test of the random director that uses actual randomness. This will be skipped on platforms where srandom(1) does not result in the same deterministic sequence of random numbers as on FreeBSD and Linux. r3386 | phk | 2008-11-11 20:06:55 +0100 (ti., 11 nov. 2008) | 5 lines Implement restart in vcl_hit. Fixes #365 r3387 | phk | 2008-11-11 20:07:30 +0100 (ti., 11 nov. 2008) | 3 lines Regression test case for ticket 365: restart in hit. r3388 | phk | 2008-11-11 21:22:05 +0100 (ti., 11 nov. 2008) | 8 lines Make sure that set obj.ttl = 0s means that the object is not hit again by actually using "-1" instead. This works around the rounding error which otherwise causes the object to be inside TTL for up to one second - epsilon. r3401 | tfheen | 2008-11-18 14:29:34 +0100 (ti., 18 nov. 2008) | 5 lines Make malloc print max storage size storage_file prints the maximum storage size, make malloc do the same, for consistency. r3402 | tfheen | 2008-11-18 21:53:03 +0100 (ti., 18 nov. 2008) | 5 lines Document grace Thanks to perbu for suggested documentation Fixes 355 r3407 | tfheen | 2008-11-19 17:26:16 +0100 (on., 19 nov. 2008) | 4 lines Correct defaults in varnishd.1 The defaults for thread_pool_min and thread_pools were wrong; fixed. r3408 | phk | 2008-11-20 09:50:56 +0100 (to., 20 nov. 2008) | 3 lines Check ECONNRESET r3418 | tfheen | 2008-11-22 02:35:16 +0100 (lø., 22 nov. 2008) | 2 lines Fix typo r3420 | phk | 2008-11-24 11:05:55 +0100 (ma., 24 nov. 2008) | 5 lines Update license to remove the advertising clause, reflecting similar change in the FreeBSD original. Approved by:des r3426 | tfheen | 2008-11-24 15:04:42 +0100 (ma., 24 nov. 2008) | 4 lines Fix typo (s/timeout/interval/) in default parameters for backend health Thanks to Jonny @ globo for noticing. r3463 | ingvar | 2008-12-18 10:47:05 +0100 (to., 18 des. 2008) | 1 line Changed rpm summary string as requested by the Fedora project ---
