3 ms·
The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous ser
by eric_h 10y ago
The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us.
In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero performance issues with redis-rb (latency caused by redis is measured in single digits, usually < 5ms).
- nirvdrum 10y agoThe tricky part with performance is it's often contextual. I didn't mention it, but I did verify the results by modifying redis-rb to remove the layers of blocks as well. Of course, it could have been something else, like how a particular method handled a block it was provided. My intention wasn't to rail against redis-rb. It's written very nice, idiomatic Ruby. The faster solution was decidedly less Ruby-like. I was just suggesting that even when your profile looks to be telling you the DB is to blame, you should probably prod a bit more. ActiveRecord is as another case where I've hit performance issues. I had just swapped out most AR usage for Sequel, so my data on that is probably well out-of-date. But, for us, materializing rows as full DAOs was often a very costly process that could dominate the cost of the DB query.
- eric_h 10y agoYes indeed, context is everything. I've had my own troubles with activerecord as well.