For the adminpanel of our CMS, it turns out some customers like to have a lot longer than aproximately 30 minutes to save data in the administration panel. They get distracted or get a phonecall... and then instead of the data being saved as they expect, they have to log in again and lose changes.
I have tried to keep the session alive with an ajax call Javascript does not call file
That first seemed to work, but eventually does not have the desired effect. If I leave the browser alone, the session dies after 1-2 hours. (I save a timestamp to a textfile every 5 minutes, so I can see exactly when the session stopped being alive).
I have been reading a lot about this issue, apparently the garbage collector kills off sessions anyway, if they are around longer than the session.gc_maxlifetime set in php.ini
My consideration is now, to set the session.gc_maxlifetime in the php.ini much higher and then set the session.gc_maxlifetime lower in a php config file for the clients who do not need this. Also for the frontend I don't want the session to be alive for hours. This way I turn it around and controll the sessions that are not supposed to last longer then default.
Would this be good practice? Will this create undesired effects?
Any advice on the path to take or possible other solutions?
Related
I've editted my php configs to save sessions on redis. Everything is working fine but I realized that one day has gone and by running command KEYS * on redis-cli, shows a huge list of php-session entries. My question is if php will remove these keys at any moment or I have to do something for that happen. I got worried with that.
I did some tests and can tell you YES, PHP remove entries added by its session manager system into Redis. You can verify that by changing option session.gc_maxlifetime = XX in /etc/php.ini, where XX is the time in seconds to collect the expired sessions.
Recently my webhost changed the PHP configuration. The only complaint I have is that sessions expire while in use.
Generally, I just write once to the session, but read many times, so I thought this may be because the filemtime wasn't changing, so every time I read, I also write by incrementing a counter. Still nothing, after 24 minutes, whether the session is being used or not, it gets cleared.
Any ideas on how to fix this?
PHP constantly reads and writes the session data file when you start a session and end the script (or call session_write_close()), so the file mtime should change. There is no need to change the atime option of the filesystem.
But things can easily go wrong beyond that, including having strange cronjob scripts running that delete session files. Without you complaining at the service desk, they will never fix it.
ini_set('session.cookie_lifetime', 259200);
ini_set('session.gc_maxlifetime', 259200);
session_start();
I have the above bit of code included on every single page on my site. I want to keep the user logged in for three days after logging in, but if they visit the site before the expiry date, it keeps them alive for three more days. Basically, the session is kept alive three days from when they leave the site (and if they don't return within those three days).
I've noticed, however, that sessions are kept alive for about a day and then die despite the ini_set I have above. I considered that perhaps it was my webhost's php.ini, but it also does this on my local machine.
Is there some other ini_set call I can do to get my desired effect? These don't seem to work, although they do keep it alive for one day.
As the size of a session gets larger, you'll run into various quirks though: not sure about current version, but PHP 5.1.x was loading the whole session into memory at session_start(); with a 20 MB session and 50 concurrent users, your scripts start to be severely limited by disk access speeds (a.k.a. "script startup is slow as molasses" - the sessions alone are hogging a GB of RAM, you definitely don't want your server to start swapping out); in the end, we dedicated a box to keep as many sessions as possible in its RAM, and the frontend boxes accessed them over NFS (although it helped in our case, this may be overkill for you).
Note that for many concurrent users and session storage on disk, the number of session temporary files may cause problems with filesystem limits (e.g. how many files can be in one directory), or other limits (we once found the hard way that a box was configured to only allow 4096 open files at the same time). None of this is really session-specific, but can be triggered by session handling.
For some odd reason, just today our server decided to be very slow during the starting of sessions. For every session_start, the server either times out after 30 seconds, or it'll take about 20 seconds for it to start the session. This is very weird, seeing as it hasn't done this for a very long time (the last time our server did this was about 7 months ago). I've tried to change the session to run through a database instead, and that works fine, however, as our current website is built, it'd take days to go on every page and change the loading of sessions to include a new session handler. Therefore my question remains:
Why is it so slow, and why only sometimes?
We run on a dedicated hetzner server with 24GB's of ram, and a CPU fast enough to just run a simple webserver (a Xeon, I believe, but I'm not sure). We run debian on the server with an apache+fastcgi+php5 setup.
The server doesn't report much load, neither through server-status as well as the top command. Vnstat reports no problem whatsoever with our network link (again, that wouldn't result in a slow local session handling). IOtop reports no problem with processes taking over the entire harddrive. Writing to the tmp folder where the session files are located works fast if done through vim.
Again, to make this clear, my main concern here isn't whether or not we should switch to a DB or a memory-cached version of the sessions, it's simply to ask why this happens, because everything I take a look at seems to be working fine, except for the PHP itself.
EDIT:
The maximum file in our PHP tmp directory is 2.9 MB, so nothing that should make an impact, I believe.
UPDATE: I did never figure out what was wrong and/or how to fix it, but the problem disappeared after we switched over to memcached/db sessions.
Have you tried session_write_close(); ?
This will disable write-ability in session variables but you can still read data from them. And later when you need to write a session variable, reopen it.
I have also suffered from this problem but this thing worked like a charm. This is what i do:
session_start(); //starts the session
$_SESSION['user']="Me";
session_write_close(); // close write capability
echo $_SESSION['user']; // you can still access it
I had the same problem: suddenly the server took 30 seconds to execute a request. I noticed it was because of session_start(). The first request was fast, but each next request took some 30 sec to be executed.
I found that the session file in c:\wamp\tmp was locked by the first request for some 30 sec. During this time the second request was waiting for the file to be unlocked.
I found out it had something to do with rewrite_mod and .htaccess. I disabled rewrite_mod and commented out every line in .htaccess and it works again like a charm. I don't know why this happend because I don't remember change any settings or conf on wamp.
I ran into this problem too. It was answered here:
Problem with function session_start() (works slowly)
Sessions are locked by PHP while one script is executing, so if scripts are stacked under the same session, they can cause these surprisingly long delays.
Each session is stored by apache as a text file.
When session start is use to resume an existing session (via cookie identifier for example) maybe a big session file (a Session with a lot of content inside) can be slow to be started?
If this is the case probably you application is putting to much data into sessions.
Please check if you have correct memcache settings e.g. in /etc/php.d/memcached.ini
I know this is an old question but I've just fixed this issue on my server. All I did was turn on the bypass cache for the domains in the cache manager in the cpanel.
My sessions were taking ages to start and close now they are instant.
Sessions also may start slow if you put many data in it. For example 50MB of data in session in docker image may result in 3 seconds of session start time.
In order to do things quickly while developing, I'm keeping the browser window opened on a particular page (which is reached after logging in and doing some other stuff that takes around a minute or two). I'm simply assigning the old session id in test case setup and it is working fine with persistent settings.
However there is one little bit of problem. After every (I think around 30 minutes of inactivity), the browser session times out and running the test case takes 2 minutes. Its not a really big deal but certainly annoying while developing. Is there a way to fix it so that browser default session timeout can be increased.
Im using PHP but it really does not matter if I can find the solution for one language, its easy to figure out for others.