PHP and MySQL
PHP sessions across multiple web servers
Choose sticky sessions or shared session storage and account for locking, expiry and failure.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Local filesystem sessions work on one server but fail when requests move between replicas. Sticky routing can reduce movement but weakens failover; a shared store provides consistent access but adds latency, locking and another dependency.
What this means in plain English
PHP sessions often store login and short-lived user state. Files on one web server work until traffic is spread across several servers. A later request may reach a different server that cannot see the original session file.
Sticky routing tries to keep one user on one server, while shared session storage makes state available to all servers. Shared storage improves movement and failover but becomes another service to secure, monitor and keep fast.
Where should session state live?
| Local | Simple, tied to one instance |
|---|---|
| Sticky | Routing dependency and uneven load risk |
| Shared | Portable state with external-store operations |
A simple example
A user logs in through web-1, then the load balancer sends their next request to web-2. With local files, they appear logged out. Moving sessions to a shared store fixes that, and a test removes web-1 during an active session to prove failover.
What to do, step by step
1. Measure session size and access pattern.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on local: simple, tied to one instance. Write the result down so you can compare it later.
2. Choose failure and consistency behaviour.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Set secure cookies and expiry deliberately.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test replica loss during an active session.
Finish by checking the result against shared: portable state with external-store operations. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Keep sessions small. Large objects increase network and locking work and can make every request depend on moving unnecessary data.
Common mistakes and how to avoid them
Scaling replicas without moving session state.
This gives a misleading or unsafe result because it leaves out local. A better approach is to measure session size and access pattern, then check the result before making the change permanent.
Storing huge objects in sessions.
This gives a misleading or unsafe result because it leaves out sticky. A better approach is to choose failure and consistency behaviour, then check the result before making the change permanent.
Treating the shared store as backup.
This gives a misleading or unsafe result because it leaves out shared. A better approach is to set secure cookies and expiry deliberately, then check the result before making the change permanent.
Words explained
- PHP
- The programming language that runs the server-side part of many websites and applications.
Quick checklist
- Measure session size and access pattern.
- Choose failure and consistency behaviour.
- Set secure cookies and expiry deliberately.
- Test replica loss during an active session.
Common questions
What is the simple answer?
Local filesystem sessions work on one server but fail when requests move between replicas. Sticky routing can reduce movement but weakens failover; a shared store provides consistent access but adds latency, locking and another dependency.
What should I check first?
Start with local: simple, tied to one instance. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Measure session size and access pattern. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Scaling replicas without moving session state. Avoiding that one mistake makes the rest of the comparison much more trustworthy.