Skip to content

Releases: mwpastore/dalli-rate_limiter

v0.3.0

13 Feb 00:21
Compare
Choose a tag to compare

Oh no, another breaking change! Didn't we just have one of these? Move fast and break things, right?

In the spirit of Mike Perham's latest blog post, "Kill Your Dependencies," I've decided to remove Dalli::RateLimiter's dependency on the connection_pool gem. Let me be crystal clear that Dalli::RateLimiter is still 100% usable with connection_pool, you'll just have to add the gem to your project and create the instance yourself if you want to use it. It was barely even a code change (seriously, take a look at the diff).

This is the only significant change of this release. Even the benchmarking results I posted about in the v0.2.0 release and README still stand. Again, if you want to use a ConnectionPool, just 1. add connection_pool to your Gemfile, 2. instantiate it (e.g. $dalli = ConnectionPool.new { Dalli::Client.new }), and 3. pass it to Dalli::RateLimiter.new as the first argument. That's it!

Hopefully this will slim down folks' bundles and help them be more aware of the gems they're actually using.

v0.2.0

08 Feb 23:23
Compare
Choose a tag to compare

I'm very excited to announce a new release of Dalli::RateLimiter! This release addresses several shortcomings of the original version. The locking scheme has been greatly improved, leading to much better performance and fewer lock timeouts. The average number of round-trips to Memcached has been greatly reduced, from seven plus one per lock attempt to two per lock attempt, leading to much less wall-clock time and load on the network and the backing store. Additionally, Dalli::RateLimiter will no longer hold a connection while waiting for a lock, so the ConnectionPool should perform more optimally.

To give you an idea of the improvements from 0.1.x to 0.2.0, my benchmarking shows that the new version can process 100,000 requests under heavy concurrency (100 threads) in about one tenth of the time as the old version; about 4,000 iterations per second (cf. 400). Moreover, the new version completes the benchmark with zero lock timeouts (cf. over 3,000). The numbers are even more favorable when the kgio gem is loaded. Information about these simplistic benchmarks can be found in the README.

In addition to these improvements, I've added a new block form that will perform a sleep-while loop on your behalf, and yield to the block when it can. This extremely convenient method should help adoption of this library and improve compatibility with other, similar libraries (like Sidekiq::Limiter). This method accepts an optional wait timeout and an error is raised when the timeout is reached. An example of this new syntax can be found in the README.

The biggest breaking change is that locking can no longer be disabled. Instead of its own mutex, Dalli::RateLimiter now relies on Memcached's built-in opportunistic locking scheme. This means that the rate limiting is now more "correct" and reliable, but at the cost of some flexibility. The lock timeout can be adjusted and a custom error is raised when the lock timeout is reached. Please see the README for more information.

Additionally, instead of raising DalliError, Dalli::RateLimiter now raises its own LockError and LimitError when a lock cannot be obtained or a wait timeout is reached. Please see the README for examples.