04:17:48 GMT <raar> hey guys
04:18:35 GMT <raar> when seeing "eviction" stats (in elasticache, but I guess it's the same some normal installs), anything that's higher than 0 means Redis didn't have enough memory to allocate new keys, right?
04:18:46 GMT <raar> or does it also include keys that are expired?
09:49:05 GMT <cloudbud> why the timeout value is required in redis.conf
10:09:59 GMT <badboy_> cloudbud: what makes you think that it is required?
10:53:26 GMT <cloudbud> @badboy : the client connection will get closed after specific idle time
10:55:32 GMT <badboy_> that's the intention of the setting, yes
10:57:09 GMT <cloudbud> okay
10:57:27 GMT <cloudbud> @badboy : what should be the optimal settings of redis server ?
10:57:36 GMT <cloudbud> any doc or any blog
10:58:23 GMT <badboy_> that highly depends on your requirements
10:58:52 GMT <badboy_> how long do you expect your clients to be idle?
10:59:09 GMT <badboy_> are your connections shortlived anyway? than choose a rather small value in order to disconnect clients that are somehow stuck
10:59:19 GMT <badboy_> tend to have long lasting connections? choose a higher value
10:59:31 GMT <badboy_> do you have reconnection logic on the client side?
10:59:32 GMT <badboy_> ...
10:59:38 GMT <badboy_> there's no one specific answer
10:59:43 GMT <badboy_> if there would be it would be the default ;)
10:59:56 GMT <cloudbud> @badboy : I am talking about the optimal redis like for all parameters like how can i finetune
11:00:49 GMT <badboy_> again: "optimal" depends on your enviornment
11:01:12 GMT <badboy_> most of these things tend to be chosen by experiment
11:01:30 GMT <badboy_> I have 30second timeouts for redis server where I only expect shortlived connections anywax
11:01:33 GMT <badboy_> *anyway
11:05:29 GMT <cloudbud> okay
11:05:37 GMT <cloudbud> no doc for finetuning ?
11:08:09 GMT <badboy_> not that I especially know of
11:08:15 GMT <badboy_> the other defaults are pretty good already
11:08:34 GMT <badboy_> and should be more or less good documented
11:08:44 GMT <badboy_> so you can adjust them once you actually hit problems
18:12:25 GMT <Foad_NH> https://gist.github.com/foadnh/8ff8a341d77edf3a0d86863a9acae2ba Can anyone help me with this issue?
18:12:48 GMT <Foad_NH> We are using C# .NET,
18:16:54 GMT <Foad_NH> Our benchmark on Redis: https://gist.github.com/foadnh/82111b1052112184c329f9e366d1d976
18:17:04 GMT <Foad_NH> We don't have network problem.
18:17:59 GMT <Foad_NH> Our C# library: https://github.com/StackExchange/StackExchange.Redis
18:43:10 GMT <zpojqwfejwfhiunz> as per usual, the client connection pooling is to blame
18:43:59 GMT <zpojqwfejwfhiunz> you are going to have to read and understand fully how StackExchange.Redis.ConnectionMultiplexer works and how pooling is implemented and then do some debugging/logging to understand the state the connections are in
18:44:44 GMT <minus> ergo it's best to write your own client library?
18:45:02 GMT <zpojqwfejwfhiunz> 1796729s is ~20 days, there was a keepalive during that time it looks like, but you shouldn't let an unanswered write persist that long
18:45:29 GMT <zpojqwfejwfhiunz> minus: if you have the time and wherewithal, then "maybe"
18:46:03 GMT <zpojqwfejwfhiunz> else, it's best to choose a client library that seems to fit your needs and then fully read and understand its docs and code for the portions you will build your production applications on
18:46:56 GMT <zpojqwfejwfhiunz> connection handling and pooling is a hard problem class [concurrent I/O], so tread carefully