1

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).

Improve this question
7
  • 1
    It's more a question of how often these settings are being used. If you are reading them and then using them alot it probably makes more sense to load them in the session. Also if you are finding that every single page you are repeating that loading code. Probably a good candidate for the session too. Commented Dec 23, 2010 at 22:08
  • If you don't know - always go normal way. That means have only one instance of data. Thus, keep it in the database. And, to let you know, thousands of user is nothing. Commented Dec 23, 2010 at 22:18
  • @Col. Shrapnel - I am aware that thousands of users is "nothing" .. I'm more thinking on the order of thousands of simultaneous users :) Commented Dec 23, 2010 at 23:59
  • Well, what architectural questions you have already solved, beside this one? Software, hardware? what are bottlenecks? Is this particular question being bottleneck or not? What filesystem operations your code do perform beside opening and locking session? Commented Dec 24, 2010 at 5:53
  • @Col. Shrapnel - not sure where other bottlenecks may occur ... as I already said: this is kinda early in the design, and I'm just looking to get some of the more obvious things "right" first :) Commented Dec 27, 2010 at 20:22

3 Answers 3

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

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.

Improve this answer

1 Comment

DB is also hitting disk, anyway. As you said httperf or AB is best way to understand it. Actually no1 can predict it without trying. Because there are hundreds of conditions influences the performance.
2

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.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.