- I am looking for the broccoli.
- It's over there.
- I am looking for the spinach.
- It's next to the broccoli.
- What's broccoli?
If conversations went like this, everybody would hate their lives. (It's also profoundly opposed to how real conversations go.)
Roughly speaking, however, this is how HTTP (or any other request-response protocol) interactions progress. Which is fine for simple actions (authentication, for instance: just say swordfish and you're in), but not for real life, and therefore not for anything like (a) the web is now, or (b) where the web is going. This is why sessions are so important -- why two-way sessions are now being built into new web standards, for example.
But sessions introduce some real technical problems -- especially when scaled. Sessions are ongoing conversations -- but if the service interlocutor is really just one physical machine, and that one physical machine just happens to be talking to bunches of people at once..or if one server just happens to be having some really intense conversations, say, with a particularly important client..then service will be slow, and unnecessarily so.
To the rescue comes Johannes Schlüter, who proposes:
A nice solution for this would be to store the sessions in a central repository which can be accessed from all web servers.
True; and Johannes already showed how to use MySQL 5.6's memecached API to speed data access from all servers (a post in itself well worth reading).
We need MySQL Cluster and an API node. Now instead of building a C++ module specific for that but why built such a specific solution when a more generic one exists? - The mentioned Development Milestone release of MySQL Cluster 7.2 includes a new form of API node: memcached.
Very practical, very well-explained post. Read it and make your PHP sessions fly like the wind.