How to stop users being logged out after about 3 or 4 hours.
Development and Programming
On a standalone PHP file on the web server, put:
<?php
echo '<pre>'.date()."\n\n";
print_r($_SERVER);Hit it and refresh and make sure you’re reaching both servers. Load balancer configuration notwithstanding, there are a few common issues that can affect the web server’s ability to detect valid sessions when load balanced servers are involved:
- date and time is wrong on one of them, have actually seen this a lot
- if there is more than one load balancer,
REMOTE_ADDRis changing, doesn’t represent the user (it’s the IP of the load balancer), and X-Forwarded IP addresses are not being trusted in ExpressionEngine because you have not set up a proxy_ip whitelist - a proxy_ip whitelist is setup, but is missing an IP for one of the load balancers, or has a typo
Ok, you are 100% right it has to do with the load balancer, and the reason (wait for it - second hint has arrived) is because of the session state of the users connection. If you read thru the documentation at AWS on load balancer stickiness you will see there are 2 types of stickiness - one is controlled by the load balancer - the other is controlled by the application (that would be EE in this case). Now we have found that load balancers at AWS can and will drop a user’s stickiness (connection state) for certain reasons using Its own stickiness - even if the browser window is not closed by the user (some of the reasons are in the Doc’s - you just have to read VERY carefully to understand what they are saying).
I could go over all the things you could do to help with that issue (because there is more than one solution to this problem), however, because I don’t want to type a book and since you’re under the gun (and we don’t want you shot), I’ll give you the short quick answer, but you will have to implement it - I’m under the gun on a development project myself and can’t spend un-paid time helping (even paid time would be rough right now), sorry.
When you enable load balancer stickiness this sticks a user to the instance they first connect to, and that means you LOSE the round-robbin nature of a load balancer, i.e. it can’t switch a user to another instance if that instance gets too much traffic. This means you aren’t really balancing the load that well from users – and if the load balancer detects the load is too high on the instance it will cut off people regardless of the stickiness setting. Bottom line stickiness is very very bad and should only be used in very specific cases – and only if you’re willing to spend the extra $$$ to have beefier instances running behind it. For a high traffic site the 2 silver bullets are:
- CDN - The more hits you can offload to something other than your instances – the smaller an instance you have to use, and if you’re using AWS CDN with S3 the traffic bandwidth served thru the CDN is actually CHEAPER that what you pay thru an instance – it actually saves you money – weird but true – take a look at the cost of bandwidth from the CDN vs. an instance, it’s lower. Plus you gain back all that computing power, it’s a no-brainer for sure. 😊
- Load Balancing – A must for a high traffic site, it gives you better security because you can completely isolate the instances behind the load balancer in a VPN and not expose it to ANY outside traffic (we never attach public IP’s to the instances behind the load balancer – use NAT if needed). And of course it lets you scale from 10,000 users a day to 1,000,000 in real-time (ours will scale up to the max 10Gb allowed –we’ve actually tested it), good if you may get traffic 100x+ over your normal traffic because of an ‘event’. If you use stickiness you blow the wonderful nature of the balancer and now must use larger instances (more $$$) to handle the sticky traffic, and it isn’t pretty unless you enjoy running huge servers that idle most of the time (or they get overloaded and you have another issue). Ok, I have to stop there because there is many more advantages too – I just don’t have the time right now.
I could go on forever on this, but to cut to the quick what you need to do is keep the connection state active for the user – i.e. their session, and the best way to do that is use your Db as the session handler. By default the system uses the file system to hold session data – which is fine most of the time for a single server – bad for multiple. Soooo, if you move your session handler to the DB you now have something in common with all instances for the session data and it won’t matter what instance the user is on – any instance can access the session data thru the Db – tada SUPER STICKINESS! Here is the funny part – we have found out that moving the session data to the Db is actually FASTER that using the file system – that one caught me by surprise.
Just move your session handler to the Db, make the configuration changes necessary to utilize it – bang – problem solved.
Ok that is my gift to the community for this year – Pe@ce Out 😊