Maascamp

I can believe it. I once worked at an investment bank where, during bonus time, I needed to deal with an issue at a trading desk. While there I had the following conversation with a particularly angry fixed income trader.

  Me: Hey Trader, what's got you so pissed off? 
  Trader: Just got my bonus. I got 13MM, but Trader2 got 16MM! Can you believe it?! I made way more money than Trader2 this year!!! 
  Me: ...

His anger had nothing to do with total dollar amounts. It was only that someone he rates himself against made more.

Nice problems to have.

Comment · 9 years ago

How come the millionaire Duck Dynasty cast member isn't an "elite," but everyone brought in by the Democrats was?

Comment · 10 years ago

The amount of garbage Scala generates doesn't get enough airtime IMO. There are at least five instances I've been part of where an underperforming Scala component was rewritten in Java for significant performance improvements, mostly due to significant reductions in GC.

Comment · 10 years ago

Not sure if this applies to their use case since they mention FIFO in the context of it being a simple eviction policy, but if you _require_ FIFO semantics then both Redis and memcached are out of the question since they use nondeterministic LRU policies (memcached's LRU is particularly egregious in its nondeterminism due to the way slab allocation works).

Comment · 10 years ago

The use case in mainly deduplication of a high volume data stream (though it's got a few other uses). The write volume is fairly stable so it's sized in such away that we'll never emit dupes even when the upstream source crashes and needs to be rebuilt from backups (for this case that means > a billion cache entries). Something like the opposite of a bloom filter (https://www.somethingsimilar.com/2012/05/21/the-opposite-of-...) didn't work because we don't want false negatives either. Since the cache is fed by a Kafka log HA is achieved simply by having multiple consumers individually populating their own cache instance. The persistence mechanisms are to allow for code deployments that don't blow away the cache, not HA.

We actually experimented with grid caches (ignite in particular since it offers off-heap in memory storage as well), but the performance simply isn't there. At the volume we're writing even millisecond latency is a non-starter. We did explore both memcached and redis, but we need strict FIFO and both of those solutions provide nondeterministic LRU.

Comment · 10 years ago

I confronted a similar caching requirement (in my case the cache needs to be much larger) in Java recently and chose to implement off-heap for some of the reasons you mention. It avoids GC and heap size concerns entirely and makes it easy to tune the rest of the application's GC profile. Systems handles 45k writes/sec and about double that for reads with very low latency minimal CPU. Implementing concurrent writes/eviction without typical Java concurrency controls was a bit tricky though.

Project is here for those interested: https://github.com/Maascamp/fohlc

Comment · 11 years ago

An important difference with the web is the barrier to entry. Testing an idea for the web is orders of magnitude cheaper (time and money) than an idea for an app.

Comment · 11 years ago

I wonder if this has implications for the higher levels of hypertension found specifically in African Americans.