00:29:31 GMT <chatter29> hey guys
08:56:37 GMT <ante> HI :) one question, maybe someone had a same problem. I have 3 nodes in redis master slave replica ( A , B , C ). After i shutdown master A, node B take role of master. And now problem is that node C never connect on master B as slave.
08:59:24 GMT <ante> sentinel log : https://gist.github.com/galicante/1bb26dc32f7f5a99c6c604e8c196027b
12:44:05 GMT <ante> docker specific problem :)
12:46:58 GMT <ahfeel> ante: ah, you found the solution ?
12:48:12 GMT <minus> Docker - for the extra serving of non-determinism in your production system
12:51:51 GMT <ante> jep. I bind sentinel on address 0.0.0.0 because of docker network layer. And set ip address of `mymaster` => `private ip` . You getting a picture :P
14:01:20 GMT <jobin> help
14:01:56 GMT <jobin> how to implement multi threading in redis /help
14:05:32 GMT <AnteNsoft> you cant. But what can you do its setup eg. 4 redis instances and setup load balancer in front of them.
16:30:05 GMT <granitosaurus> Could someone help me wrap my head around my issue: I have a website that allows users to check few tickboxes(up to 10). Now for every tickbox a redis call to specific key is made. This would happen pretty much on every page. How can I optimize this?
16:30:26 GMT <granitosaurus> so far from what I've heard redis caches stuff like that automatically?
17:54:21 GMT <minus> granitosaurus: What do you mean on every page? Load everything? What's the performance issue/concern?
17:55:53 GMT <granitosaurus> minus, so right, let's presume I have 100 users and every page some data for these users needs to be retrieved that require 5 redis calls to retrieve sets.
17:56:09 GMT <Inge-> Welcome back Mr__Anderson. We've missed you!
17:57:21 GMT <granitosaurus> but I think I just answered my own question.
18:03:56 GMT <minus> granitosaurus: rubber duck effect. good for you then; i'm still lost a bit :D
18:05:09 GMT <granitosaurus> minus, to elaborate a bit more, my goal is to reduce redis calls. if I have 100 users that make my web app call redis 500 redis sets every 20 seconds, that's quite a bit, isn't it?
18:05:12 GMT <minus> you could pipeline the requests, or try to store them in just one key instead of 5, or use a lua script to assemble the data in redis, but nothing of that will give a big benefit
18:05:55 GMT <granitosaurus> so I decided just cache those sets in app memory instead. Though since redis is runs in memory I'm not certain anymore if there's any difference here
18:06:08 GMT <minus> 25k queries per second; yes, that's quite a bit, but shouldn't be a problem for redis on a moderately decent machine
18:06:30 GMT <minus> well, you save the roundtrip to redis
18:06:46 GMT <Inge-> with batching, even a Raspberry Pi manages around 30K get req's/sec :)
18:06:49 GMT <minus> if you're sure the data won't change in redis caching it is fine, i guess
18:07:06 GMT <granitosaurus> "a moderately decent machine", does 5 euro linode count? :D
18:07:07 GMT <minus> really
18:07:29 GMT <minus> i have something with ~40k req/s in the back of my head on an i7 or so
18:07:34 GMT <DrEeevil> more than ~70k queries/sec is difficult with a single redis instane
18:07:38 GMT <minus> might have been complex requests
18:07:43 GMT <DrEeevil> but then you should ask yourself why you do that
18:07:56 GMT <minus> redis-cli --benchmark time!
18:09:53 GMT <minus> >98135.42 requests per second
18:10:21 GMT <minus> (redis-benchmark -t get)
18:11:05 GMT <granitosaurus> only 45k on my x220 :/
18:11:11 GMT <granitosaurus> oh wait
18:11:17 GMT <granitosaurus> that's my linode vps :D
18:11:24 GMT <granitosaurus> pretty damn good if you ask me
18:11:32 GMT <minus> decent
18:11:46 GMT <granitosaurus> my laptop does 120k
18:11:52 GMT <minus> the 98k was on my i5-4210U
18:12:00 GMT <Inge-> network latency, CPU speed and RAM speed?
18:12:09 GMT <minus> >220604.45 requests per second
18:12:20 GMT <minus> on one of our i7 servers at work
18:12:25 GMT <minus> (consumer hardware)
18:12:54 GMT <Inge-> locally or over network
18:13:09 GMT <minus> local ofc
18:13:42 GMT <minus> odd
18:13:49 GMT <minus> the instance is passworded
18:13:53 GMT <minus> that shouldn't even work
18:15:07 GMT <minus> 195k if i set the password, 28k over network (one router)
18:15:57 GMT <minus> 151k over network (over one setswitch)
18:16:17 GMT <minus> switch, not setswitch, where the fuck did that set come from
18:16:39 GMT <minus> incredible how much difference a router makes
18:21:21 GMT <minus> granitosaurus: and you can't consolidate those 500 queries you do in one page load? 500 seems quite excessive
18:22:03 GMT <granitosaurus> oh no, 500 queries per ALL users i expect
18:22:08 GMT <granitosaurus> so 5 queries per page per user
18:22:18 GMT <minus> ooooh
18:22:30 GMT <minus> so 25q/sec
18:22:40 GMT <minus> no worries about that then
18:23:14 GMT <granitosaurus> half-way through implementing the cache :D
18:23:18 GMT <granitosaurus> now you tell me!
18:23:32 GMT <minus> you didn't correct me when i said 25k q/sec!
18:23:38 GMT <granitosaurus> but yeah, I'd rather not have this cache
18:23:44 GMT <granitosaurus> not a mathemagician, sorry
18:23:59 GMT <minus> yeah, caching is bad
18:24:45 GMT <granitosaurus> well, thanks for clearing up then minus!
18:24:57 GMT <Inge-> There are only two hard problems in computer science
18:25:02 GMT <Inge-> Naming things
18:25:04 GMT <Inge-> Cache invalidation
18:25:08 GMT <Inge-> and off by one errors
18:25:14 GMT <minus> lol
18:25:19 GMT <minus> that last one i didn't know
18:25:45 GMT <minus> the other variant is s/Cache invalidation/Distributed systems/, but that's very similar
18:27:12 GMT <Inge-> also some interpolate multi threading
18:27:47 GMT <Inge-> anyway. Don't add an unnecessary cache :)
18:27:58 GMT <minus> it's all got to do with shared state that needs to be synchronized
22:19:42 GMT <xrated> hi, I've just started hunting down a performance issue - according to newrelic most all commands are performant but hget is incredibly slow
22:19:52 GMT <xrated> idk if anyone has ran into some sort of similar situation?