That's why using another DB, as suggested Mike ("write to a separate
database"), could be a good test...
Jacques
Le 24/11/2015 18:23, Nick Rosser a écrit :
Got it, thanks Mike.
Nick
-----Original Message-----
From: Mike [mailto:mz4whee...@gmail.com]
Sent: Tuesday, November 24, 2015 12:23 PM
To: user <user@ofbiz.apache.org>
Subject: Re: VISIT and VISITOR Entities
at least not OFBiz cache since
I didn't mean the ofbiz cache. I meant the database (mysql/postgres) cache
settings.
On Tue, Nov 24, 2015 at 8:34 AM, Nick Rosser <nros...@solveda.com> wrote:
Thanks Mike -- don't think this is a cache issue -- at least not OFBiz
cache since it is not showing up in the OFBiz Cache maintenance page.
Nick
-----Original Message-----
From: Mike [mailto:mz4whee...@gmail.com]
Sent: Tuesday, November 24, 2015 11:31 AM
To: user <user@ofbiz.apache.org>
Subject: Re: VISIT and VISITOR Entities
Most likely this table is stealing cache memory from the rest of the
tables. Either increase cache memory, delete the rows, write to a
separate database, or keep the table trim to xxx rows (as Adrian said)
via an internal ofbiz job or external script (via crontab).
On Tue, Nov 24, 2015 at 7:48 AM, Len Shein <lsh...@solveda.com> wrote:
All,
We have a LIVE application in which the VISIT AND VISITOR entities
have grown to over 19 and 18 million rows respectively.
Has anyone experienced any performance issues when these entities
have grown to such capacity?
We recently had a performance issue and decided to turn off the
visit history feature until this feature can be ruled out as the issue.
stats.persist.visit=false
stats.persist.visitor=false
Note: The application is currently using Ofbiz r.10.
Len Shein
<mailto:lsh...@solveda.com> lsh...@solveda.com
O: 516.742.7888 x225
O: 732.333.4303
C: 917.882.8515
