LBRYCommunity/ccache
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
ccache/cache_test.go

67 lines
1.7 KiB
Go
Raw Normal View History

The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
package ccache
import (
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
. "github.com/karlseguin/expect"
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
"strconv"
removed print line to fix #1
2014-03-23 00:52:26 +01:00
"testing"
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
"time"
)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
type CacheTests struct{}
func Test_Cache(t *testing.T) {
Expectify(new(CacheTests), t)
}
func (c *CacheTests) GCsTheOldestItems() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
cache := New(Configure().ItemsToPrune(10))
for i := 0; i < 500; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
//let the items get promoted (and added to our list)
time.Sleep(time.Millisecond * 10)
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("9")).To.Equal(nil)
Expect(cache.Get("10").(int)).To.Equal(10)
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
func (c *CacheTests) PromotedItemsDontGetPruned() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
cache := New(Configure().ItemsToPrune(10).GetsPerPromote(1))
for i := 0; i < 500; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
fixed tests
2014-02-28 16:50:42 +01:00
time.Sleep(time.Millisecond * 10) //run the worker once to init the list
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
cache.Get("9")
time.Sleep(time.Millisecond * 10)
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("9").(int)).To.Equal(9)
Expect(cache.Get("10")).To.Equal(nil)
Expect(cache.Get("11").(int)).To.Equal(11)
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
func (c *CacheTests) TrackerDoesNotCleanupHeldInstance() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
cache := New(Configure().ItemsToPrune(10).Track())
for i := 0; i < 10; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
item := cache.TrackingGet("0")
time.Sleep(time.Millisecond * 10)
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("0").(int)).To.Equal(0)
Expect(cache.Get("1")).To.Equal(nil)
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
item.Release()
cache.gc()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("0")).To.Equal(nil)
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
}
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
func (c *CacheTests) RemovesOldestItemWhenFull() {
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
cache := New(Configure().MaxItems(5).ItemsToPrune(1))
for i := 0; i < 7; i++ {
cache.Set(strconv.Itoa(i), i, time.Minute)
}
time.Sleep(time.Millisecond * 10)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(cache.Get("0")).To.Equal(nil)
Expect(cache.Get("1")).To.Equal(nil)
Expect(cache.Get("2").(int)).To.Equal(2)
This is a sad commit. How do you decide you need to purge your cache? Relying on runtime.ReadMemStats sucks for two reasons. First, it's a stop-the-world call, which is pretty bad in general and down right stupid for a supposedly concurrent-focused package. Secondly, it only tells you the total memory usage, but most time you really want to limit the amount of memory the cache itself uses. Since there's no great way to determine the size of an object, that means users need to supply the size. One way is to make it so that any cached item satisfies a simple interface which exposes a Size() method. With this, we can track how much memory is set put and a delete releases. But it's hard for consumers to know how much memory they're taking when storing complex object (the entire point of an in-process cache is to avoid having to serialize the data). Since any Size() is bound to be a rough guess, we can simplify the entire thing by evicting based on # of items. This works really bad when items vary greatly in size (an HTTP cache), but in a lot of other cases it works great. Furthermore, even for an HTTP cache, given enough values, it should average out in most cases. Whatever. This improve performance and should improve the usability of the cache. It is a pretty big breaking change though.
2014-04-08 17:36:28 +02:00
}
Reference in a new issue Copy permalink