Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What is the best and most safest way to handle PHP sessions. Is the best way to store sessions in:

  1. Database (more reliable, but high bottleneck, slow speed, not good for high database usage websites)?

  2. Memcache (super fast, but distributed more security problems, chances of loosing data when the server restarted and chances of loosing data when the cache is full)?

  3. Files (default option, I guess slow since it reads and writes from file I/O, less security, etc).

Which method is the best? What are the problems and good things of each of those approaches?

share|improve this question
2  
I believe you should specify if you're using only one machine, or if the application is distributed, since it will heavily influence the answers. –  MainMa Nov 5 '12 at 9:00
1  
@user1179459: you need to work on your accept rate. Also, this is more of a question for Stack Overflow. –  haylem Nov 13 '12 at 22:14
    
@haylem this is the most appropriate place to ask this question, its not programming question its programming conceptual problem, –  user1179459 Nov 13 '12 at 23:28
2  
This is really a poor question because 'best' depends on your specific circumstance. The 'best' for Facebook is probably not the same 'best' for your personal home page. –  GrandmasterB Nov 14 '12 at 4:22
    
@GrandmasterB i know that thats why i clearly asked "What are the problems and good things of each of those approaches?" to find out which one is the best for me. –  user1179459 Nov 14 '12 at 7:52

6 Answers 6

It depends on your needs.

There are some differences between files and database storage. See this question.

However, you can do what's done in Rails 3 by default, and use only encrypted cookies for your session. So you encrypt all values in a way that only you can decrypt it later (e.g. private/public keys), and you let the client do the state keeping for you.

On the one hand it limits you to 4Kb, which is actually usually enough (since you usually want to store IDs, not whole objects), but the really nice benefit you get is that you don't need to worry about session cleanup. You leave that up to the client, where it actually should be.

share|improve this answer
1  
Unless you've separated out your static resources to be outside your cookie path, cookies are a fixed tax you have to pay on every request. –  Joeri Sebrechts Nov 5 '12 at 8:36
    
jQuery and Bootstrap are around 150kb combined, and that's without other libraries. Cookie max is 4kb, and usually below 1Kb. Unless the OP is asking about extreme circumstances - who cares about that kind of taxation? –  Yam Marcovic Nov 5 '12 at 17:14
    
@YamMarcovic there are few problems 1) cookies are going to server too (users usually have faster download then upload) 2) usually pages have 100's of requests for static files (images,js,css) so it can get into 100kb on each request going up –  Miro Svrtan Nov 11 '12 at 18:18
    
@MiroSvrtan If you're making your users send hundreds of requests per page (where did that ever happen?), optimization is clearly not an issue for you. –  Yam Marcovic Nov 11 '12 at 20:48

The best is to store at Memcached as we can easily resolve the other issues (cache size, security, etc.)

facebook is the #1 consumer of memcached. Please read if interested: http://www.facebook.com/note.php?note_id=39391378919

How to resolve the other issues?

share|improve this answer

For my particular situation, I can tell you that sessions in a database is the number one cause of our server hang-ups by a good margin. our sessions table gets corrupted frequently enough that we have taken to truncating it pre-emptively.

memcache sounds attractive, but we have too many processes that clear the entire memcache, so user sessions would be cut off too frequently. and the older sessions would be cleared as memory became full... so no more permanent logins.

We'll be trying the default file-based sessions soon.

If you are worried about security of your session data, then you shouldn't put that data in the session - and don't trust the session - validate the user on every request.

share|improve this answer

What about using the MEMORY storage engine in MySQL?

It is not as fast as Memcache but has the advantage that you can use plain SQL, and you can also use the normal storage engine when it will not be needed and switch to MEMORY when the number of users/requests grows.

I'm using it for storing large amounts of statistical data in a web app which changes frequently so it is not used for handling sessions but I think it should be well suited for this purpose.

share|improve this answer

For the vast majority of day-to-day applications, keeping sessions in databases is fine. The volume & level of concurrency that a sql server can handle will be more than sufficient. The key is to keep each entry small in size and purge the unneeded rows with regularity. And proper indexing, of course.

The file system - I've never seen the need to do that. I prefer the simplicity of managing rows in tables rather than thousands of little files. Plus you cant query across files if you want to dig into session statistics.

Keep in mind, with PHP, its easy to swap out session handlers. So you can start with one storage format, and migrate to another without too much hassle.

share|improve this answer

You can try to save your session on Redis. Redis is fast like Memcached but also has several data-persistence options. In addition, various PHP clients are supported.

In addition, you can try 3rd party services like the Memcached Cloud that has built-in replication and storage engine capabilities

Disclosure, I'm Co-Founder and CTO of Garantia Data.

share|improve this answer
2  
Thanks for the disclosure! Do make sure that you participate on this site beyond posts where you can mention your own products though, we want you as a person to contribute, not your company. –  Martijn Pieters Nov 18 '12 at 13:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.