Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

PHP Sessions on Steroids

DZone's Guide to

PHP Sessions on Steroids

· Performance Zone
Free Resource

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

  • Hello.
  • Hello.
  • I am looking for the broccoli.
  • It's over there.
  • Hello.
  • Hello.
  • 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).

But for a more scalable, more fundamentally distributed solution, check out his new post on using the MySQL Cluster for PHP session storage. Here's his idea, in a nutshell:

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.

And he goes on to explain how and why to use memecached (rather than memecache with no d) for exactly this purpose.

Very practical, very well-explained post. Read it and make your PHP sessions fly like the wind.

Learn tips and best practices for optimizing your capacity management strategy with the Market Guide for Capacity Management, brought to you in partnership with BMC.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}