The way it is set up there are 2 cache nodes in a cluster - a primary and a secondary. Then I have a seperate address to connect to the cache cluster - so there probably is some sort of proxy there, but I can't manipulate it - it's in the AWS Elasticache offering. I don't want to bypass the proxy, because if the primary goes down, it won't automatically failover if I don't use it. I could however test to bypass it just to see if that changes anything.
Also I have setup the sessions backend via the PyPI package django-redis-sessions - so it handles the connections for me. I don't know if it reuses the connections or not - however looking at the monitoriing of the redis server, it doesn't have that many connections - I think the django-redis-sessions plugin has a short timeout value. However this has worked perfectly until just a month ago, so I don't really see why these changes have come now. Med vänliga hälsningar, Andréas Kühne Software Development Manager Suitopia Scandinavia AB 2016-12-06 15:46 GMT+01:00 GMail <[email protected]>: > You didn't answer about proxy. Also, do you reuse connections to > redis.example.com? Or create a new one for every request? If you aren't > reusing them, maybe you should add timeout for connection creation and > retry creating after timeout has exceeded. I know this doesn't solve the > problem, but at least you wouldn't have to wait for server timeout. > > I still think something is proxying your request to redis.example.com and > this something is what gives you timeouts and connection errors. > > On 6 Dec 2016, at 17:41, Andreas Kuhne <[email protected]> wrote: > > Hi, > > Thanks for you answer - I don't think the problem is with django either, > but thought that maybe someone else has run into the same issues on AWS. My > cache cluster worked fine for over 2 year as well, but now, not so much :-) > > 2016-12-06 14:35 GMT+01:00 GMail <[email protected]>: > >> Hi! >> >> Do you by any chance have any proxy on top of Redis? Seems like Django >> has nothing to do with it, though. >> >> I don't know anything about dynamodb really, but I think implementing >> Django cache with dynamo as backend should work. I've implemented Redis >> Cluster cache for my project and it works fine. Here're the docs about >> session engines: https://docs.djangoproject.com/en/1.10/topics/http/ >> sessions/#using-cached-sessions >> >> On 6 Dec 2016, at 15:55, Andreas Kuhne <[email protected]> >> wrote: >> >> Hi, >> >> We are having a strange problem with our redis elasticache instances on >> AWS. We have our sessions stored in a redis cluster on AWS. Our webservers >> sometimes get a: >> * Error connecting to redis.example.com:6379. timed out >> * Timeout reading from socket >> >> (I haven't included our real domain for the redis servers :-)) >> >> Both of these are related to our webservers connecting to our redis >> server. This started about a month ago, and worked perfectly for nearly 2 >> years before that. I really don't understand why this is happening. I know >> that the webservers have access to the redis servers, so I really can't >> understand the problem. Has anyone else experienced a similar problem? >> >> That was the first part of my question, my second is related to this >> though. For costsaving I would really like to dump the redis cluster and >> change to a dynamodb based session store. I have found a pypi package that >> works for the implementation, but when I tried it about 2 years ago, it >> failed miserably. We ended up having people get new sessions all the time >> and the sessions weren't being persisted corrrectly (each request ended up >> generating a new session). >> >> Has anyone successfully implemented a session store on dynamodb? With 2 >> webservers behind an loadbalancer? >> >> Also, has anyone any ideas of how to move the sessions from our redis >> store to the dynamodb database? >> >> Any tips / tricks would be very appreciated. >> >> Regards, >> >> Andréas >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/django-users/CALXYUb%3D89GTJ33FgE_DpjofdgOn2fYqVoctzo00N >> Oq5K26Twmw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CALXYUb%3D89GTJ33FgE_DpjofdgOn2fYqVoctzo00NOq5K26Twmw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/django-users/13E0B717-29E6-43D5-AAD9-0FD4A4424186%40gmail.com >> <https://groups.google.com/d/msgid/django-users/13E0B717-29E6-43D5-AAD9-0FD4A4424186%40gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/CALXYUbkum1Ou5x6yTqFxz-T1pG2%3D9_Km-_XbWBiFur34dVnXyg% > 40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CALXYUbkum1Ou5x6yTqFxz-T1pG2%3D9_Km-_XbWBiFur34dVnXyg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/E58F1469-2A35-45DC-8F5D-7DC9D6E61650%40gmail.com > <https://groups.google.com/d/msgid/django-users/E58F1469-2A35-45DC-8F5D-7DC9D6E61650%40gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALXYUbm_zJa48VbEj%2BSevZQ%3DX%3DT-tR6%3DL%2Bf9Hby95Ahhpm2CHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
