Nishant

Hi, @flydev,

ASG stands for Auto Scaling Groups. (Basically there are multiple server instances running and delivering the website content. In simple terms, let's say the website is running on one server and the CPU usage has hit 60% it will automatically activate another server instance and now two instances will distribute the work.)

Below are the required details,

• Database: MySQL
• Server version: 8.0.23 - Source distribution
• max_connections: 1000
• session.save_path: /var/lib/lsphp/session/lsphp81
• session.save_handler: files

regards

@bernhard @teppo @netcarver, though disabling the SessionHandlerDB module resolved the website speed issue, but that created another major problem. As my site is running on an ASG setup, there are multiple server instances running and delivering site contents at the same time. Now the session is stored in the file system, it randomly loggs-out the processwire user when switching between the instances (Switching of instances happens on its own, we can't handle it, if I turn off all the instances and keep only 1 then it will solve the problem, but will create performance issues as the website has large number of visitors).
The only possible and reliable solution is to store the sessions on the database, do ProcessWire supports this natively without using any module?

1 hour ago, bernhard said:

That sounds like an interesting setup. I'd be very interested in a tutorial/showcase if you want and find the time 🙂 

Definitely, I will have a word with the server team and can gather the required details you need for the tutorial

On 6/26/2023 at 9:02 PM, teppo said:

Just wondering if it might be related to this: https://github.com/processwire/processwire-issues/issues/1760. Basically on some systems (mainly Ubuntu) sessions are cleared in a somewhat non-standard way, which works for disk based sessions but not work SessionHandlerDB. Site running slow could mean that the sessions table has grown so large that queries take very long time.

If that's the case, you may want to apply the solution that Bernhard suggested in aforementioned issue. Or alternatively disable SessionHandlerDB.

(Just for the record: in most cases I would advise against database sessions, unless there's a specific reason for them. Disk is usually — in my experience at least — faster and also tends to have fewer quirks. If disk based session storage is not an option, I would look into setting up Redis for session storage.)

Not sure if the session had grown large, as after uninstalling the SessionDBHandler module, the table is also removed from the database. But last time I checked under processwire panel, It was showing somewhere around 200 active sessions. (I have an RDS and ASG setup on AWS, and on the load tests it was able to handle 10000+ concurrent users. Not sure if 200 active sessions can slow down the performance so drastically)

On 6/26/2023 at 6:27 PM, netcarver said:

@Nishant happy to hear you have your site up and running again. Out of interest, and to help try and track this down...

1. what version of the SessionDBHandler module were you running (if you happen to know?)
2. are you using the MyISAM or InnoDB engine in your MySQL/MariaDB installation?

Hi @teppo @netcarver,

1. The version for SessionDBHandler was 0.0.6
2. Database engine is InnoDB

26 minutes ago, netcarver said:

It might be that module as it uses GET_LOCK. Is it feasable to switch this site back to using file-based sessions?

Yes, I have uninstalled that module and the site seems to be working fine now. Will test for couple of more days and see if that was the primary cause.

Yes @netcarver, I am using the SessionDBHandler module

Hello All,

My processwire website is running very slow, I had a word with my server support team and they said that there are multiple "GET_LOCK" queries running which is causing the server to slow down.

Attaching a screenshot of the MySQL queries below

if anyone had similar problems or know the solution then please do help.