KB Article - Slow performance

[Benjamin Dyer]

I wanted to draw your attention to a new KB article:

Slow performance when navigating content tree or adding sections

If you have between 500 and 5000 products you may find that navigating the content tree and adding sections, products etc. is slow. The performance can be improved by reducing the product cache size to a lower value.

Please be aware this work around may have a negative impact on processes that require fast access to products such as Preview and Upload.

It would be great to get some feedback, has this worked for you?

Ben

[grantglendinnin]

Thanks for bringing this to our attention Ben. I went over this with Chris J on Support and have noticed a huge improvement when moving between sections - before I made the changes I'd get an egg-timer every time I clicked between sections or products - now I rarely get this but have not noticed much difference if I actually edit any piece of product/section data (eg. name, description, price, etc).

[Benjamin Dyer]

Thats great news Grant, how has upload performance been?

[bcomp]

Speed wise editing meta title, decription and keywords is much quicker taking 1 - 2 seconds with page preview open but still not as fast as it is when the page preview is closed which is instant.

The upload site is much slower so in my case it's easier and quicker to edit details with preview closed than loose the performance when uploading.

[jont]

Ben - is there anything in development to split the field to 2 values preview / upload to get the best of both worlds?

[grantglendinnin]

Upload seems to take longer doing the 'Checking' part but other than that, it does seem to be of benefit.

[fergusw]

Ben - is there anything in development to split the field to 2 values preview / upload to get the best of both worlds?

Better yet, some automated performance monitoring within Actinic itself that sets this value based on number of products, sections, processor speed etc etc
Performance fine-tuning for the machine that it's installed on?
Are there other undocumented performance tweaks that may benefit from the community testing?

[Mike Hughes]

This change makes a huge difference to me. Editing content and moving around the tree is now 10x faster than it was before (more like 1s than 15s) even with page preview on.

I haven't tried uploading as the V9 site is still in development. If I can I'll run some upload tests and report back the results.

Will the cacheing algorithm get fixed in V9.0.4? Clearly the workaround has pro's and con's so a proper fix would be the best solution. Given that this is very similar to the problems that got fixed in 8.0.4 I would have thought the solution might already be known to Actinic. Even a simple dynamic version that Jont suggests that switches to an increased value for uploads would be helpful.

Mike

[Benjamin Dyer]

Thanks for the feedback everyone.

The first step it to make sure this works, it looks promising as it did in our lab but nothing beats real world testing.

We are looking at a possible inclusion of a fix in v9.0.4, but no promises while its still in investigate mode. I'll keep you updated.

[Mike Hughes]

Thanks Ben,

I've tried timing some site refreshes with different values of sData but all I'm getting are crashes and dmp files (tried 6 times now). I'm sure it's unrelated as it happens even with the default 2048 so I'm off to learn what to do about dmp files.

Mike

Edit: Hopefully the problem I'm seeing is this one that's fixed in 9.0.4:

# Issues causing crashes on upload and dmp errors

I'll check with support in case it's something new.

The upload checking did seem much faster with the larger cache value (2048 vs 100). Sadly I won't be able to time anything until the problem gets fixed.

[wesleythorne]

have implemented this into our site with 1000 products, running on business plus multi user, updating tags and adding new sections much quicker, moving sections around much faster, but of cause you have to log out all over user first.
A little bit slower on upload but will be monitoring this to see how it performs.

Not noticed any slow down yet with a second user logged in, although you cant move sections with a second user logged in.
Wesley

[wesleythorne]

ok, uploading is not good with this, keeps crashing actinic, have increased the value from 100 to 500 and the upload is smoother but works although a bit slow.
wesley

[Benjamin Dyer]

OK, thanks for the update, is there a specific point when it causes problems?

[guccij]

This has speeded up things a lot for me, and I am at the lowest end of the scale in terms of product numbers.

However, the first upload crashed out with a .dmp so am reverting to the larger cache for now.

[Mike Hughes]

OK. I've run some upload tests with different values for the cache.

Around 1,400 products, no external linking.

sData and Upload time (checking only as nothing's changed):

2048 (default): 4m 15s
250: 4m 35s
200: 4m 20s
150: 4m 20s
100: 4m 35s

I ran this with a few different values as my first test at 200 seemed to give an odd result of 5m 50s, but after seeing very similar results for other values a retest gave a more consistent value. (bad science I know but I'm not trying to prove something scientifically here).

Refresh time:

I thought a refresh would be a good test of checking and upload but I can't do a refresh at all. It crashes every time at the moment no matter what I do.

Purge and refresh:

2048: 6m 40s
200: 7m 20s

So the lower value of sData takes about another 40s to purge and refresh (only tested once each time as this all takes time to do).

My initial conclusions from this quick test are:

a) While I'm editing content for the website, as I am now, then I'll definitely use the lower value of sData. The speed advantage is huge.

b) The upload (checking) times seem fairly close to me so as long as there's only minor changes to upload I don't see much problem in using the lower value for sData.

c) Something's buggered as I can't do a refresh without actinic crashing. Hopefully this is fixed in 9.0.4 and maybe Actinic support can fix my database anyway. They thought they had with the purge and refresh but apparently not.

Mike