Multiple reads and writes to cf_client_data in the same request

dev support
1

Hi,

We have 6 webservers running a Lucee application behind a loadbalancer. Client session data is stored in a database and is shared between the servers. The database is in an Availability Group, which means that it writes all changes to a transaction log, and the log needs to be backed-up periodically to release the used log space.

The servers get around 1 million requests a day, some moments way more than others. This causes a lot of session data reads/writes, so a lot of transaction log writes. Around 1GB a minute!
The back-up takes longer and slows the IO of session reads/writes down.

While researching this I saw the following in Fusion Reactor. The same request does two consecutive reads on cf_client_data, then an update and an insert, all with the same CFID.

Is this normal?

Many of those requests do not need to store anything in the client scope. Can I enable/disable session management per request?

image

Session related code in application.cfc:

	<cfset this.name = this.getApplicationName() />
	<cfset this.clientManagement = true />
	<cfset this.sessioncluster = true />

	<cfset this.clientStorage = variables.CSDSN />
	<cfset this.sessionManagement = true />
	<cfset this.sessionTimeout = CreateTimeSpan(0,10,0,0) />

OS : Windows Server 2019
Java Version : 11.0.15+10
Tomcat Version : Apache Tomcat/9.0.62
Lucee Version : 5.3.9.141 and 5.3.10.120
Microsoft JDBC Extension Version : 11.2.3

2

see LDEV-3340 Do not store empty session/client scope to storage

use the env var / sys property lucee.store.empty=false to skip saving empty sessions (which is the default in 6.0)

3

Thanks, I will try this next.

I realized that we were storing a lot of unnecessary data in the client scope and doing a lot of background calls to the backend from each open browser tab. These two factors combined meant that powerusers who used more of the application had 0.5-4 mb of data… and every tab they had open would touch the session multiple times a minute and had to write this to the transaction log for synchronizing/back-ups.
We reduced the data and the frequency off those calls and that helped a lot.