SMF Support > Server Performance and Configuration

Sessions slows down SMF when used PHP 7.0!

(1/2) > >>

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


--- Code: ---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;
}

--- End code ---


Please look at this line:


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

--- End code ---

drewactual:
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.

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. 

Navigation

[0] Message Index

[#] Next page

Go to full version