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:
REMOTE_ADDR
is 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 whitelistOk, 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:
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 😊
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.