Jared Moody

You either die a hero, or you live long enough to get purchased by salesforce, be neglected for years, try to squeeze your customers for enterprise contracts, give them false hope of a new platform only to pull the rug and declare maintenance mode. RIP #heroku #rails #ruby

@andrewm.codes @excid3.com every time you pronounce mise “mize”, a new bug manifests on ruby core

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

So, to deal with this, I used some private APIs (danger!) to read out and de-serialize the Cache::Entry objects (with their versions intact!), not the actual values that Rails.cache.read / read_multi returns. Then I wrote those entries out just like the Cache Store does under the hood.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

The unintended result of this is that the cache for the user does not bust when the AR object is updated because Rails has no version to compare with. Rails.cache.read [@user, 'greeting'] will return the stale value even after @user is updated.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

Given a User ActiveRecord with an id of 1, Rails.write [@user, 'greeting'], 'hello' and Rails.write 'users/1/greeting', 'hello' both write a serialized Cache::Entry object with a value of 'hello' to the same cache location.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

A fancier approach might have been to write a custom store to dual-write, but I was ok with losing the cache writes from the time it took the pre-warm to run.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

What surprised me though was that the 5GB I copied only used ~ 2.25GB of DB Storage in SolidCache. Dug into the source a bit, and the SolidCache Store is doing some compression that the RedisCacheStore is not. So we're looking at effectively 10x the size.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

As expected, better hardware is faster. The prod Redis cache pulled 1k keys averaging 0.528ms per key (while also serving prod requests), SolidCache in 0.752ms per key. Seems SolidCache is plenty fast for web applications.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

This was on an RDS instance *without* directly attached storage, but also with significantly fewer keys than prod would have.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

Then I did 1k reads or writes and summed the times from Benchmark.ms. Not scientific but enough to get an idea. Writes were about 2x slower, which sounds bad, but we're talking like 5ms vs 2.5ms, not enough to matter.

I deployed #solidcache into production today. In the past I've asked around about what kind of performance people had been seeing and gotten back nothing, so, a quick thread about my experience, and a subtle gotcha to avoid if pre-warming/transferring. #ruby #rails

At <day job>, our app servers are on Heroku, our database an RDS #postgresql cluster, and our old #redis cache was on the very solid but very expensive RedisToGo. We're talking $500/mo for 5GB of redis memory. Yikes.

You crazy bastards, I won’t be awake but I’m in.