Mike, list, hello. > > 1) Hmm, the "persistence mechanisms" sounds interesting. Is it > totally out of the question? > Well, a persistence mechanism would have to store the data somewhere, anyway. This would be either: a) on the filesystem (which would introduce security and permission issues) or b) in the database (why bother? It's already in the database!) or c) in the session, which would only partially alleviate the problem, because each visitor has his own session, meaning that any subsequent request from a given user wouldn't have to re-read the data off the database. Obviously this would also introduce another overhead, because PHP would have to read and write the session data from disk. In a nutshell, I usually use this kind of mechanisms when the Object I want to persist takes a relatively large amount of computing resources to build and its lifecycle timespan is large enough. This is where persistence engines like Hibernate come in quite handy, but our current situation doesn't qualify, IMO. > You're right, they're not big tables and MySQL can handle them with > aplomb. That said... hundreds of users/hundreds of page loads... it > all adds up. Again, query caching can mitigate this, so I'd highly > recommend making a prominent suggestion that folks make sure it's > turned on. Good point, I'll add some code to check whether the cache is tuned on, and that would warn the user when it's not. > > One thing I didn't mention before, the memory storage engine might be > worth looking into for those two tables. > Unfortunately the HEAP (or Memory) storage engine doesn't support TEXT columns. Also, the gist of those table is to store user settings, which we don't want to loose, when the mysql server is restarted and the the table content is wiped. > 3) Cool. I implemented this in changeset 1516 http://svn.gregarius.net/trac/changeset/1516 let's see how it behaves! Best, -m