Create sessions only for logged in users?

Powerhead2012-09-07 19:30:29

PHP

Powerhead, 2012-09-07 19:30:29

The session mechanism in php is such that for each unique visitor, a session identifier file is created on the server. With the influx of visitors, too many files were created.
I want to consult, does it make sense to run a session exclusively for logged in users, since there are much fewer of them?

If the client has cookies with session id, then the client is logged in, then run session_start ()
If there are no cookies, then it is not logged in, we do not start the session.

Will respected gurus tell me if this will help to win in server performance?

Answer the question

In order to leave comments, you need to log in

11 answer(s)

rakot, 2012-09-07
@rakot

Store sessions in Redis

Vampiro, 2012-09-07
@Vampiro

IMHO you are digging in the wrong direction. Creating a file is an extremely cheap operation, better optimize your "Bitrix" ...

cronfy, 2012-09-08
@cronfy

The consequence of having session_start() at the beginning of the script is that if the client does not support cookies, then a session file is created per request . And all sorts of robots quite often do not support cookies.
Once again , a new session file is created for each robot request .
If your sessions are stored, say, 24 minutes (by default), then this still does not really affect. But when you decide to increase the session storage time to a month so that the user is not thrown out of the trash, then pretty soon you will have a million files in tmp/. As a result, PHP will run slowly and waste server resources when opening a page or cleaning up garbage.
So the recommendation is: store sessions for users who store your cookies. We put a cookie, we check on the next request whether this cookie exists, if so, we can run session_start().
The option is simpler, without cookies, and even fewer sessions will be created: create a session only for the one who logged in. That is, until the username and password match, we do not run session_start().
Any not very important data that you need for all users (for example, the city from which the user came), store in cookies.

If the client has cookies with session id, then the client is logged in, then run session_start ()
If there are no cookies, then it is not logged in, we do not start the session.

If there is a cookie with the session ID, then you have already called session_start(), which means that the session file has already been created . Check nunjo in some other way (for example, by matching the entered login and password, as described above).

Arthur Koch, 2012-09-07
@dudeonthehorse

Why an unlogged sid? I'm not talking about optimization. Just logically. Don't, don't start.

Nikolai Vasilchuk, 2012-09-07
@Anonym

I don't separate users. For everyone, the session starts and rights are given. For anonymous - a minimum of rights, for authorized - more.

R0ckwi11, 2012-09-07
@R0ckwi11

And sessions in general and in a DB it is possible to store, I recommend.
Even if now a session is not needed for unlogged users, it may be needed later, so IMHO it's worth

impass, 2012-09-07
@impass

I want to consult, does it make sense to run a session exclusively for logged in users, since there are much fewer of them?

In fact, this is how it should almost always be. The developers of certain web applications themselves often have a poor idea that a wasted session created until the moment of actual authentication is not needed for anything. For the purpose of collecting any visit statistics, it is worth inventing a solution that does not depend on the main session: setting cookies for additional subdomains or specific site paths, etc.
In cases where, for example, it is necessary to configure caching of backend responses on heavily loaded sites, disabling session creation for each incoming one is simply vital.

stanishevsky, 2012-09-08
@stanishevsky

And in a very good way, in addition to creating a session only for logged in users (which, generally speaking, is correct), put a reverse proxy in front of the web server - nginx or varnish (I recommend the latter), which will check for the presence of cookies of the logged in user, and in case its absence to issue content from its cache. This way you won't run PHP for unlogged users at all.
Here, for example, is how this problem is solved in Drupal (it doesn’t matter what you have, the principles are most likely the same) www.varnish-cache.org/trac/wiki/VarnishAndDrupal

Angerslave, 2012-09-08
@Angerslave

Authentication is just a special case of using sessions. In general, if the session is not needed, then there is no point in starting it. But many modern frameworks do this for the purpose of unification, since it is really inexpensive.

egorinsk, 2012-09-08
@egorinsk

You need to encapsulate all work with sessions in a separate class. Then you can easily change storage and session creation mechanisms without touching the rest of the application.
You have already been advised to store sessions in radish, you can also try to store them in the database.

softm, 2012-09-08
@softm

Why not try it, the idea is good, in my opinion.
There might be some speed gain.