01:38:15 GMT <olalonde> what happens when Redis runs out of memory?
01:39:38 GMT <olalonde> I want to use Redis for caching some http responses but am wondering if I should limit how many responses I'm caching somehow
01:41:12 GMT <olalonde> just found https://redis.io/topics/lru-cache
01:41:36 GMT <olalonde> does redis delete least recently used keys when running out of memory?
01:55:40 GMT <adamg> random question. is it plausible (iow, has it ever been reported) that the expiration algo outlined here https://redis.io/commands/expire could result in intermittent (a few times per hour) 60-90s long periods of spinning cpu?
02:34:23 GMT <adamg> read into the many-keys-with-same-expireat, but we only use expire
11:08:17 GMT <kuso> Hi all, just a quick question on RLEC OS support
11:08:32 GMT <kuso> is there any plan to support SLES systems on x86 ?
13:26:33 GMT <tgy> is it possible to send multiple pubsub messages in the same time?
13:26:43 GMT <tgy> instead of one by one
13:48:09 GMT <Habbie> tgy, doesn't look like it - why?
13:50:30 GMT <tgy> Habbie: i was thinking that bulking them would make things faster
13:50:47 GMT <Habbie> the redis protocol supports pipelining
13:51:01 GMT <Habbie> or you could pass a long list of messages to a short EVAL script, if your client does not support pipelining
13:52:52 GMT <tgy> oh actually my client can do it :D
13:52:54 GMT <tgy> thanks :)
13:54:24 GMT <Habbie> ok!
14:37:28 GMT <minus> i wonder if using a binary protocol would make a significant performance difference for redis
14:40:18 GMT <badboy_> the protocol is pretty binary already :P
14:40:34 GMT <badboy_> you could certainly reduce the amount of bytes sent
14:40:39 GMT <Habbie> i've been pondering this but indeed it is pretty binary already
14:40:48 GMT <Habbie> even if it doesn't look like that
14:40:53 GMT <badboy_> (right now there's at least 3 bytes overhead per argument)
14:40:55 GMT <Habbie> it is not doing 'parsing' in the sense your shell does
16:12:18 GMT <minus> well, it needs strcmps for commands and flags like WITHSCORES
16:12:34 GMT <minus> also, floats and ints need to be parsed
16:12:47 GMT <Habbie> yes and yes
16:21:27 GMT <minus> that was not a question
16:37:00 GMT <badboy_> yeah, the actual work could be reduced
16:37:15 GMT <badboy_> but then again I wonder how much of the time is actually spent in parsing the format
16:39:10 GMT <badboy_> what makes the current format so nice is that it is fully binary-compatible and still human-readable
20:50:57 GMT <ezyang> For some reason, my client library is generating keys that look like "\x00\x00\x00\n". Anyone know if there's an obvious reason why this is happening?
20:51:06 GMT <ezyang> like, a well known gotcha or something
20:52:43 GMT <Habbie> hi ezyang
20:52:52 GMT <Habbie> i don't have an immediate hunch
20:53:03 GMT <Habbie> is this your own client lib or are you just driving some existing client lib?
20:54:18 GMT <ezyang> hiredis
20:55:30 GMT <Habbie> haven't used that one but i understand it's quite popular which should mean that statistically this is your fault and not the lib's
20:55:37 GMT <ezyang> haha
20:56:00 GMT <Habbie> this is a serious concept ;)
21:43:51 GMT <minus> you must be doing something wrong, ezyang, like passing wrong parameters. i've had hiredis smash the stack due to that (passing incompatible integer types to format arguments)