News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Sessions slows down SMF when used PHP 7.0!

Started by mktek, February 09, 2018, 12:37:09 PM

Previous topic - Next topic

mktek

Hello SMF heroes,

Sorry for my bad English. This is an important issue.

I have a very powerful mysql server. I reach 20.000+ online user when I use PHP 5.6 (15 min, smf+portal) If i use PHP 7.0, the site reaches maximum of 3.000+ online user. And it is slowing down excessively. I have been searching for a long time, but I have not found a solution. But i guess this is about sessions table.

Last week I finally found the exact problem and solution. SMF is deleting smf_online table at intervals of 30 seconds. But deleting smf_sessions table every request. There is no problem when there are few online users. If the online users increase, the site is locked.

The workaround I found is here. I believe you will find better. Best regards.

file: forum/Load.php


function sessionGC($max_lifetime)
{
global $modSettings, $smcFunc;

// Just set to the default or lower?  Ignore it for a higher value. (hopefully)
if (!empty($modSettings['databaseSession_lifetime']) && ($max_lifetime <= 1440 || $modSettings['databaseSession_lifetime'] > $max_lifetime))
$max_lifetime = max($modSettings['databaseSession_lifetime'], 60);


        if(mt_rand(1,100) !=1 ) return false;  /******* I added the this line. *********/


// Clean up ;).
$smcFunc['db_query']('', '
DELETE FROM {db_prefix}sessions
WHERE last_update < {int:last_update}',
array(
'last_update' => time() - $max_lifetime,
)
);

return $smcFunc['db_affected_rows']() != 0;
}



Please look at this line:


          if(mt_rand(1,100) !=1 ) return false;  /******* I added the this line. *********/


drewactual

#1
there is a setting in your httpd as well to assist in garbage collection- setting the interval and the count work together (having count @100 and interval @1 will cause a 1% likelihood of session being destroyed).  this will assist in keeping things tidy.  it is directly related to the alteration you made to load.php above...

another valuable item is using sessions handler as 'memchached' as opposed to 'files', and setting the directory to your static and dedicated IP and port 11211 .. it would be a value of simply xxx.xxx.xxx.xxx:11211, without concern for "" or tcp in that line at all (which was required in </= php5.5) ...  obviously, memcached has to be operational in your apache build.  this memcached isn't to be confused with the files cache.... with the number of visitors your seeing, having the server store sessions (as in 'files') is an i/o event each time- pushing those over to the client (such as memcached, and xxx.xxx.xxx.xxx:11211) is a lot cleaner and not a little faster, a LOT (especially with that kind of traffic). note that port 11211 is 'out of the box' port, and can (but likely shouldn't) be changed to suit your needs.  Using memcached and storing them elsewhere keeps your sessions very tidy perpetually.

and something else that is off subject but which may benefit you is implementing OPCache, which stores and reuses scripts in RAM as opposed to re-running them at each and every call... my site literally went from 6~8seconds of DOM loading time to averaging ~1.5 seconds when i introduced OPCache... I made a thread in the server board on how to do this... with the traffic your seeing, it would be a boon!!!!

edited to add: the greatest benefit of OPcache isn't even the speed you'll collect, but instead the load on the server which doesn't have to collect and then execute those scripts each and every time... as an example, my modestly pathetic SMF went from having 50~60 concurrent users, 10MB of download, and pegging the machine @95+% of processor function to the exact same 50~60 concurrent users and 1MB of download @ ~5% processor function... it makes that big of a difference and is the #1 thing to do to a machine in my humble opinion... meaning- even if you destroyed every session every time, you'd still likely not crash the server.

shawnb61

I believe drewactual is right on target.   

The garbage collection routines are called by PHP/Apache based on your php.ini settings; this is not strictly an SMF function.  I suspect these settings need a serious review/revisit if you are calling garbage collection every request. 

The settings are:
   session.gc_maxlifetime
   session.gc_probability
   session.gc_divisor

You can read up on them more here:
https://www.dev-metal.com/how-the-php-session-garbage-collector-really-works/

Could you share your values for the 3 settings above? 

The net effect of your 1/100th logic was to increase the gc_divisor by 100 times.  I believe if you made that update to php.ini, that would have the same effect as your custom line of code.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

mktek

Thank you for your answers @drewactual @shawnb61

I did not know that. My values below:

session.gc_probability = 0
session.gc_divisor = 0
session.gc_maxlifetime = 1440

shawnb61

Yikes, that explains it...

I'd experiment with a probability of 1 & divisor of 1000 or so, removing your custom line of code, and seeing if that improves things. 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

drewactual

Quote from: mktek on February 09, 2018, 01:35:13 PM
Thank you for your answers @drewactual @shawnb61

I did not know that. My values below:

session.gc_probability = 0
session.gc_divisor = 0
session.gc_maxlifetime = 1440

.... and there it is!!!  :)

in my humblest opinion, and i am but an observer- i'd set to :
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440


this will give a tenth of a percentage chance a session will be destroyed for users who selected 'always keep me logged in' when they attempt to reinitialize a session....

also in my humblest opinion- I'd march away from using sessions:files as assertively as i could, install (or request your host install) memcached, and alter the same ini file to sessions handler: memcached and the directory to (your machines IP):11211 .... let the clients deal with it and keep your sessions table clean!

shawnb61

For an extremely busy forum, you might even want a divisor of 1000000 or so.   
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

mktek

@drewactual @shawnb61

Thank you so much. I learned something new today. I'm so happy. :)

I've been in vain for a long time. :)

Thanks...

Aleksi "Lex" Kilpinen

So, are we ready to mark this topic solved then? :)
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Advertisement: