After update from 3.7.4 to 3.7.5 there is still issue with too many guests in joomla online module when you use in session handler"database" . Please check the test that i made viewtopic.php?f=706&t=958997&p=3512762#p3512856
To be sure if with redis there is no issue i will tell you tomorrow.

ribo wrote:After update from 3.7.4 to 3.7.5 there is still issue with too many guests in joomla online module when you use in session handler"database" . Please check the test that i made viewtopic.php?f=706&t=958997&p=3512762#p3512856
To be sure if with redis there is no issue i will tell you tomorrow.

Joomla is not arbitrarily deleting records from the session table anymore when you use the database session handler, this operation is deferred to native PHP handling (as is the case with all other handlers). Joomla will only purge old records from that table when not using the database session handler and on a much shorter frequency than before the 3.8.4 release (the odds of the cleanup operation being fired have dropped from 50% in a minute to 20%).

mbabker wrote:
Joomla is not arbitrarily deleting records from the session table anymore when you use the database session handler, this operation is deferred to native PHP handling (as is the case with all other handlers).

Why it happens that? And what do you suggest? To not use database in session any more? And if we use php in session instead of database, will joomla be faster or slower?

mbabker wrote:
Joomla is not arbitrarily deleting records from the session table anymore when you use the database session handler, this operation is deferred to native PHP handling (as is the case with all other handlers).

Why it happens that? And what do you suggest? To not use database in session any more? And if we use php in session instead of database, will joomla be faster or slower?

Joomla has two types of session data: The "real" session data (whose storage location is defined by the session handler configuration), and "optional" session metadata (this is what lets you see a list of logged in users in the backend or use the Who's Online module). The optional metadata is stored in the session database table regardless of handler configuration, and if using the database session handler then the "real" data is stored to that table as well.

Arbitrarily running the `DELETE FROM session` query as was the behavior at 3.8.3 and earlier meant that Joomla was performing PHP's session garbage collection task, but ONLY for the database handler (if using any other handler, this same arbitrary cleanup task was not happening). So Joomla's code has been giving preferential treatment to the database handler because it stores two types of data into one database table and to correctly remove stale records it has to delete both the optional metadata and the real data.

This arbitrary `DELETE FROM session` query was hardcoded to have a probably of running on 50% of requests (if the current time was an even numbered second). And has been a result of performance issues on some sites. The changes introduced into 3.8.4:

- Changed this probability from 50% to 20%, running only on a second that is an even divisor of 5, resulting in a less frequent cleanup operation
- Changed the cleanup operation from running at the beginning of the request to the end of the request (after the HTML document is sent to the user's browser), giving a minor performance enhancement by not having this task block processing the rest of the request
- Changed the logic so that it truly only operates as a cleanup handler for the optional metadata aspect of that data storage, making the native PHP garbage collection handling consistent for all database handlers instead of having in essence a different behavior for the database storage versus other stores

No, the current state is not optimal. Yes, things are continuing to be changed. I have mentioned in several places here on the forum and on GitHub what needs to be done to get things to the most optimal state. These tasks include extracting the metadata management code to a separate PHP class so that we can create tools to run this cleanup outside of web requests (i.e. cron jobs), moving the optional data to a separate database table (which would remove the check if the database handler is in use because we would always need to manage this table versus it having shared responsibilities with the native PHP handling of sessions), or even going so far as to disabling this optional metadata tracking for sites not desiring these types of capabilities (which has rewards and tradeoffs alike).

If you have a site that is reliant on showing accurate "who's online" data, you have two viable options right now:

1) Change the session handler to any other handler; there should be minimal if any performance gain or tradeoff depending on option (if your site supports Memcached as an example, you're trading a network request to your database server for a network request to your Memcached server; using the "PHP" handler trades a network request to your database server for a filesystem read/write operation)
2) If using the database session handler, create a cron job which in effect mimics the behavior of https://github.com/joomla/joomla-cms/bl ... #L166-L185 which will in effect restore 3.8.3 and earlier behavior but will be based on a set schedule versus an arbitrary decision made by the web application class

Hello!
After updating the site from joomla 3.8.3 to 3.8.5, the database table _session, began to rapidly increase ~ 400 MB per day and is not cleared at the set time, attendance is 3-5 K per day. The session handler is the database, I put the session handler - I do not have access to the admin panel.
Every day I clean the _session table manually, logs to / var / log - did not tell anything. Tell me how to get rid of the problem.

layer8 wrote:If you session table is huge and your site is slow after update to J.3.8.5, you just need to go to your PHP configuration and set session.gc_probability to 1

Does not work, - garbage is not deleted

After updating the site from joomla 3.8.3 to 3.8.5, the database table _session, began to rapidly increase ~ 400 MB per day and is not cleared at the set time, attendance is 3-5 K per day. The session handler is the database, I put the session handler - I do not have access to the admin panel.
Every day I clean the _session table manually, logs to / var / log - did not tell anything. Tell me how to get rid of the problem.

Put session.gc_probability on 1 - does not work, garbage accumulates and remains in the database. Only after the end of the session re-enter the admin area

Since the first version of joomla 1.5, when I have not seen one, - the base for 1 day with 20 MB, grows to 400 MB!

First off, I want to thank you all for maintaining Joomla, very much appreciated.

I also had my session handler set to database and it grew quite large. Looking at the above, I changed it to php and cleared the session table in the database. I noticed that the table is starting to grow again. That doesn't seem right to me. The session handler is definitely set to php. Is there some reason Joomla is still writing to the database table? Is there a php setting I should be setting? I tried finding information, but a lot of it is outdated.

BillyS wrote:First off, I want to thank you all for maintaining Joomla, very much appreciated.

I also had my session handler set to database and it grew quite large. Looking at the above, I changed it to php and cleared the session table in the database. I noticed that the table is starting to grow again. That doesn't seem right to me. The session handler is definitely set to php. Is there some reason Joomla is still writing to the database table? Is there a php setting I should be setting? I tried finding information, but a lot of it is outdated.

BillyS

After initially growing, the session table appears to have stablized and appears to be working correctly at this point. Sorry about the false alarm.

interesting post.. I noticed my site is slower since I updated (but I also updated some nginx configs so who knows..)

I checked my db and the session table is over 450mb which never happened before.

Also what never happened before was this server (a xeon 4/8t 3x250mb ssd in raid0 with 32gb ram) not to be able to handle the traffic. I suspected some kind of get flood attack on the moment but this might be as well the too many request of the cms with the db?

So what is the best setting for performance with the session? php or db?

looks interesting, I guess J! should include this (disabled at least) in the future releases by default

"This plugin will clean the sessions table if your server configuration does not perform the automatic PHP garbage collection properly.

This can happen if the Database handler is used, the session.gc_probability value is set to 0 and the user cannot modify this value directly."

I had this session.gc.probability set to 0 because I am using ubuntu, and also despite ubuntu is supposed to replace this with a cronjob (seen https://www.appnovation.com/blog/sessio ... ection-php), I haven't seen any cron configured for that purpose. So that means now to use Joomla, users need to make specifics configuration of their OS, which didn't happen before. many users on shared hosting won't be able to make such changes..

No, users won't be required to make server level configuration changes. With the 3.8.6 update, you only need to do something if you want to tweak the default configuration or execution of the cleanup processes, and if you're doing that odds are you do have the ability to schedule cron jobs (either through cPanel or managing your system's crontab) and inherently understand these configurations. Otherwise, the default is "well enough" and over 95% of users won't have a need to understand it in depth or change it.

I've noticed that when I share an article on Facebook, the image doesn't show, does anybody know why that happens? It seems to be pretty random, it will do it one week, then not the next, it's kinda annoying, as I use infographics.. Any ideas??

Newman123 wrote:I've noticed that when I share an article on Facebook, the image doesn't show, does anybody know why that happens? It seems to be pretty random, it will do it one week, then not the next, it's kinda annoying, as I use infographics.. Any ideas??

Open a thread in the "general Forum" and not in the discussion about Joomla 3.8.5. This is not an open discussion thread for individual issues encountered

Newman123 wrote:I've noticed that when I share an article on Facebook, the image doesn't show, does anybody know why that happens? It seems to be pretty random, it will do it one week, then not the next, it's kinda annoying, as I use infographics.. Any ideas??

Open a thread in the "general Forum" and not in the discussion about Joomla 3.8.5. This is not an open discussion thread for individual issues encountered

Leo

Is that your way of saying you don't know the answer?? I was using Joomla 3.5 at the time, so I can't see how it wasn't deemed relevant, but each to their own... It seemed to sort itself out anyway after the update..

Newman123 wrote:Is that your way of saying you don't know the answer??

no, if he didnt know he would not have bothered posting

I was using Joomla 3.5 at the time, so I can't see how it wasn't deemed relevant,

so vaguely relevant and buried in a different topic that people would ignore it. would you stand in Rome railways station and ask when the train to Bath was ? you were [again] pointed to the better place to get your answer and yet you came back with an attack instead of saying "thanks but

Newman123 wrote: It seemed to sort itself out anyway after the update..