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.
Related
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?
Yes, I've read session_start seems to be very slow (but only sometimes), but my problem is slightly different.
We have a PHP application that stores very simple sessions in memcached (elasticache to be specific), and have been monitoring our slowest-performing pageloads. Almost all of the slow ones spend a majority of their time in Zend_Session::Start, and we can't figure out why. It's a very AJAX-y front end, moving more and more toward a single-page app, making a number of simultaneous requests to the backend per pageload, and some of the requests take up to three to four times as long as they should based solely on this.
It's not every request, obviously, but enough of them that we're concerned. Has anyone else seen this behavior? We were under the impression that memcache is not blocking (how could it be?), so the very worst would be a user has a bum session, but multiple-second wait times in session_start seems inexplicable.
Take a look at your session garbage collection mechanism (play with probability and divisor).
If gc is slowing down the app, consider cleaning the old sessions manually (e.g. setting gc probability to 1 and running gc script via cron).
Another possibilities:
session mechanism is locked (so the app waits to unlock, then write)
too much data saved
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.
This may seem a silly question, but having been pondering it for a few days, i've only come up with one answer, so I thought i'd throw it open and see what other people think.
I have a PHP script which runs as a CRON job, and checks that our CDN is up and running. If it is, it needs to set a flag to show 'true', if not to show 'false'. The main PHP webpages then need to check this flag everytime a user visits the site, and set the CDN URL variable appropriately.
The query is where do we store this flag? We could put it in a database, but then the database would get 'hit' every page load. Also, as we're using Memcache it could result in a delay to it being updated (although there are ways around that, obviously).
My next thought was to save it into a simple text file on the server. But a) we have load-balanced servers, and although we could run the same CRON job on each server, that seems inefficient, and b) opening and reading a text file could, i thought, slow the page load down, as its involving disk activity everytime - that isn't good when the system is delivering 3 million web pages a week!
The ideal would be PHP system variable that retains its value between pages - but of course, that doesn't exist! Its not the kind of information that should be stored as a cookie on the users machine either.
Does any one have any thoughts? All comments welcome!
If you are already using Memcache, then why do you need the CronJob at all?
Put the check for the CDN into your regular application code. Cache the result in Memcache with a lifetime of what your Cron Interval is right now. If the cache is stale, do the full checking on the CDN, otherwise return the cached result.
If you want to keep the CRON job and are concerned about Disk I/O, consider using a RAM disk or Semaphores or Shared Memory to store the results. But it seems kinda pointless when you are already using memcache.
Do you already use a database connection?
If so, use that; you can fit it into your existing replication mechanism pretty easily, I'm sure.
If not, then whatever you do here is going to add overhead, be it reading a text file on disk or reading from a database where you weren't before.
As all my requests goes through an index script, I tried to time the respond time of all my requests.
Its simply the difference between the start time (start of the script) and end time (end of the script).
As I cache my data on memcached and user are all served using memcached.
I mostly get less than a second respond time but at times there's wierd spike of more than a seconds. the worse case can go up to 200+ seconds.
I was wondering if mobile users had a slow connection, does that reflect on my respond time?
I am serving primary mobile users.
Thanks!
No, it's the runtime of your script. It does not count the latency to the user, that's something the underlying web server is worrying about. Something in your script just takes very long. I recommend you profile your script to find what that is. Xdebug is a good way to do so.
If you're measuring in PHP (which it sounds like you are), thats the time it takes for the page to be generated on the server side, not the time it takes to be downloaded.
Drop timers in throughout the page, and try and break it down to a section that is causing the huge delay of 200+ seconds.
You could even add a small script that will email you details of how long each section took to load if it doesn't happen often enough to see it yourself.
It could be that the script cannot finish because a client downloads the results very-very slowly. If you don't use a front-end server like nginx, the first thing to do is to try it.
Someone already mentioned xdebug, but normally you would not want to run xdebug in production. I would suggest using xhprof to profile pages on development/staging/production. You can turn on xhprof conditionally, which makes it really easy to run on production.