Can you tell me if the PHP sessions are a problem for a site with a big audience (is it slow ?). Are the cookies better ? (Damned, my english is so poor ! :stickout )

Thank you,

Bot

PHP sessions

Why please ? (The PHP sessions doesn't slow down a site ? )

If you're expecting huge amounts of traffic then I'd say cookies are the way to go, because each PHP session takes up disk space.

PHP sessions use cookies and url tags I believe.

Therefore PHP sessions is just a prebuilt setup for session tracking using cookies.

PHP sessions details are stored as files I believe.

If you make your own session tracking solution, using cookies more than likely, you can cross reference the content of the cookie (presumably a long random number/string combo) with an entry in an mySQL or PostgreSQL to provide session tracking. This will provide greater stability for a bigger site, and it could also allow for clustering with multiple webservers and a backend db server for session tracking.

(I could be wrong, haven't looked at the stuff for sometime)

You hit the nail on the head their Matt, all big sites use a database to track users along with cookies or an ID tagged onto the URL.

The problem with PHP sessions (by default file based) is that if you have a lot of visitors then you're going to have a lot of session files floating about and if you're really busy then you could well end up hitting the node limit on the drive partition storing the session data because of 1000s of small files.

So is it better to have 100% of PHP sessions, 100% of cookies or a mix ?

If it's a big site like you say then I would do would ignore the PHP sessions options and instead create your own session tracking solution with mysql and cookies. Of course if its a small or moderate use site then PHP sessions will work just as well and be alot easier to implement. Depends on how big your site will get.

Thanx for your answers :)

If you understand the properties of both cookies and sessions and you know well what do you want to store then it should be easy to decide.

Cookies are good when it is a small amount of data only.

Sessions are good when it is a large amount of data or when it is something that you don't want to keep for too long.

If it is the username that you want to store so it is easy for the user to login later on, then you better use cookies, because it is a small piece of information that you want stored and probably unchanged for a long time (one year or more).

It if is a shopping cart then you better use sessions to store the data. Cookies cannot store that much information.

As for PHP's sessions support vs. your own session interface, PHP's session support is just a standard inteface to session management functuality. The default implementation does use lots of small files to store session data (takes a lot of space and unsecure), you can always change that default implementation using your own functions as an implementation.

PHPBuilder.com has an example article on how to make PHP sessions use MySQL instead of small text files.

Its not clear that Bot understands that virtually all session management strategies rely on

a) cookies, or
b) stuffing a unique session id in the page URL or within a form field
c) or both a or b, sometimes falling back to b automagically if the client browser has cookies disabled.

Most session management strategies use cookies.

I agree with the database (or some other object store) for persistence of the session data on the server side, if its going to be a big site. But define big - if you can't imagine the site ever needing to span more than one server, then you have more than one choice available to you.

Just found the article:

http://www.phpbuilder.com/columns/ying20000602.php3

Commenting on Ahmad's earlier post - another reason why you decide between cookies and persistent sessions (cookies or not) is security. Anytime you are tempted to put items in a cookie that could later be used in a way you do not intend (to gain access, to change orders, etc) is a good hint that the data doesn't belong in a cookie in the first place.

When I care about security for a site, I only store session ID data within the cookie; then I'm worrying only about securing a single piece of information.

I always generate a random id number (around 60 characters or so, double-check it against a database to make sure it's not already taken) and then set a cookie with that id number for a set amount of time.

When the user logs onto the site, it will access the database and look for that id number and then provide them with the information needed.

That way, everything is stored in the database, rather then having every single thing stored in a cookie or php session.

Sounds familiar.. ;) .. I do exactly the same thing. The session specific data is pickled (Python) and stored in a single db column.

I also store & check IP addresses - if the cookie comes from a different IP than what I've stored, I force them to reauthenticate.

That's what I do on sites where security is warranted. Otherwise its a pain for the dial up / dhcp crowd.

Thanx for your answers. Now I understand why sometimes it's better to use cookies. I will try and I will tell you if I can do what I want :)