00:12 <ScottKevill> kppullin: Absolutely.

00:12 <ScottKevill> kppullin: But that wasn't the point. The point is that redis-benchmark uses 50 clients by default to get more throughput, not to be more realistic.

00:13 <ScottKevill> With redis-benchmark set to 1 client, I get 42,000 LPUSH'es per second.

00:13 <ScottKevill> With its default of 50 clients, I get 90,000 LPUSHes per second.

00:14 <ScottKevill> With my queuing system with a single client, I'm getting 280,000 LPUSHes per second.

00:15 <ScottKevill> So the point is that redis-benchmark is very far from optimal at representing the potential of redis.

00:17 <kppullin> i see. what's the difference between a single client in redis-benchmark and your system? why's it 7x faster

00:20 <ScottKevill> I haven't looked at the code recently.

00:20 <ScottKevill> From what I remember, it doesn't do any pipelining.

00:21 <ScottKevill> Ie. redis-benchmark's code

00:26 <gsin> hi... anybody run redis instances on the cloud? what providers do you guys recommend?

00:26 <ScottKevill> Ooh, I had persistence on in these tests as well.. my numbers could be even better..

00:46 <ScottKevill> Haha, 300,000 LPUSHes per second on a loaded Xeon 3220, 2.4GHz.

00:46 <ScottKevill> That rocks.

00:46 <ScottKevill> Single connection.

04:22 <antihero> How do I back up my redis database?

04:23 <ron> http://redis.io/topics/faq

04:26 <patrakov> While reading http://redis.io/topics/replication , I got a question

04:26 <patrakov> it says "When a master and a slave reconnects after the link went down, a full resync is performed."

04:27 <patrakov> is the slave able to serve stale data (i.e. at least something) while this full resync is in progress?

04:28 <patrakov> oops, sorry for the noise, found the answer

05:04 <alxgsv> Redis cluster ETA? (Hope will not be banned for this question)

05:46 <aashish> Hi guys

05:50 <ron> Hi

05:55 <aashish> I am using redis with rails, Can any one help me with 'How to see redis data in UI'.

05:55 <aashish> Note: I started redis server, and using redis-UI gem

10:56 <thinkjson> Is it faster to have lots of hashes with few keys or few hashes with lots of keys?

10:57 <ira> Test it… :)

10:57 <thinkjson> hmm

10:58 <thinkjson> since hgetall is O(n), it probably wouldn't matter either way

10:58 <thinkjson> many keys might be faster due to less HTTP requests from the API to the redis server

10:59 <af> there's a difference in memory consumption though

10:59 <thinkjson> which is more efficient?

11:00 <af> if you have less hash fields than your hash_max_zipmap_entries setting, it's more efficient

11:01 <af> depending on the size it could be just a little bit slower

11:02 <af> in other words, you should test it with real data if it really matters

11:04 <thinkjson> we would need to store something like 1M different values. I imagine we'd want to break this across several hashes. The question is how many.

11:06 <ira> Think: Do you even know that you have a performance/space issue?

11:12 <af> and hash will anyway behave quite like having the fields as keys

11:12 <af> there's not much difference except for that special case where there's just a few fields in a hash

11:56 <phretor> in a multi-threaded script, shall I instantiate one StrictRedis() object and share it among threads or let each thread instantiate its own one?

11:57 <phretor> sorry, I meant when using redis-py

14:44 <asteve> what's the default for activerehashing, no or yes?