PHP Sessions performance: array vs key into a database table?

In similar vein to this previous question, I a looking to implement user preferences on a small webapp.

Right now there are about 10 fields that a user can customize 开发者_开发问答(this may change in the future).

Does it make more sense to do an initial query into the database and bring back these preferences loading them in to the SESSION array, or only grab the ones needed on a per-page basis? None of the fields is more than about 12 characters currently.

Right now the total number of users is very small (internal development stage), but there could be hundreds or thousands of users of a given instance in the future.

I have not benchmarked any of these issues personally, and am not yet in a position to be able to do so (userbase too small).

One session managment I like is the one built in egroupware. In this system every preference can be defined by 3 levels:

• forced preference (superuser decision, user wont see it in fact)
• default preference
• user defined value

With such thing obtained an object or array with the user preferences can necessit several queries. It could as well be impacted by long-term cookies user settings.

Then there's an interest in avoiding to redo all this stuff at every request and storing the final result in the session file is a good idea. And in terms of security I don't think there's a big difference between data stored in sessions files and data stored in a database, it's all server-side, with a good admin your sessions won't be in the same directories for all applications, you'll have your application directory, no problem.

On step further. By using a session stored preference definition you loose the possibility of altering this session by modifying the defaut preference or the forced one. the preferences will be available for the session duration. If this is an issue in your case (well, most of time it's not a problem) the solution is application-level caches with a good tagging system on the way you store the data in the cache. Then you can delete all tagged data when you want.

Application-levels caches, like the APC cache or memcached will gives you a fast and effective way to store data, using it to save your user preferences can be a good idea at least to share this data between several application servers without using NFS to share the sessions files. But the real solution in such a big solution would be to use theses cache for session storage instead of files. In the same way you could use database to store your sessions.

With the last point, database session storage, you can imagine that all the queries used to build the preferences are now all contained in the unique query retrieving the session from database (which contains your preferences, after the first http query of the user session). But this is a bad solution, for most databases, as sessions get a lot of write events, and for databases like MySQL having a lot of insert/update queries in a table can lead to big performances problems (locks, query cache flush, etc). So filesystems and caches are better in managing sessions. And databases are good are keeping long-term data in a secure way, session storage is not the same problem, you want something really fast, that you can loose without too many fears (as it will only destroy the user session).

As you can see when I think about sessions I think about something more fast than database. If your system does not provides a faster way for sessions than for database I personnaly think it's a system failure, it will be a job for sysadmins. On the application side you should consider sessions like faster than databases.

Either way you're hitting the disk. There is probably less overhead to pull the session data out though, so only having the mysql overhead once is likely going to be better. As the other guy suggested, memcached or some other heap table would be a good way to avoid hitting the disk at all on subsequent page loads and will allow your solution to scale later, the default session handler won't share across servers.

BTW you could benchmark it yourself using httperf or AB, or any number of other solutions, without waiting for the user base to grow.

I'd have thought the session based approach would be the better solution (as long as there's no sensitive username/password, etc. information in there). After all, disk space is a lot cheaper than multiple database lookups.

Alternatively, you could look to use something like memcached if performance becomes an issue.