can store data in the user session, but can't store data with application
scope.
ASPs can do it, JSPs can do it, but PHP doesn't, and has no plans to any
time in the future.
For this application, it means that every single user is going to have to
grab hold of a copy of the database schema every time they start their
session. When we reach the point of tens of thousands of hits per second, we
are going to need far more power in the database than would otherwise be the
case. As it happens, this particular application is designed such that users
of a particular size are going to be happy to pay for their own, uncontended
database instance, and no single company is ever going to grow to a size
where they would need anything more.
It is the principle which counts, though.
You could simply write stuff to disk, and put up with the performance
overhead, but then you might as well use a federated or replicated MySQL
instance. A better solution is to use Memcached. It is a highly scaleable
cacheing tool with a handy PHP interface called Memcache. Install the
package, start the daemon, and throw objects at it. For private objects, use
a name prepended to the session id. For public objects like the schema, just
use a common name. Although it isn't a straightforward install, we
essentially have application scope objects.
To use the memcache interface, I would need to rewrite some code. The code
is going to first check for object existence in memcache, then read from DB
and put into memcache if it isn't already there. I probably wouldn't
normally use the options, but it is possible to put objects into memcache
with a limited time, and to restrict the memory usage of the daemon.
Not something I need to worry about yet (the apps are lightning-fast), but
good to know there's a solution when I need one.
No comments:
Post a Comment