Speeding up Actinic - Dev Team Query.

[gabrielcrowe]

I'm trying all the tricks under the sun to get actinic faster.

Everything, including installing it on a system with only sufficient services installed to make it work. Stripping out all other applications.

I tried the fastest hard drive, ram and cpu i could find. a 10,000 rpm drive and ddr2 ram. A dual cpu xeon board.

I'm not really getting anywhere fast, for a catalog with squillions of products.

but what i'd really like to know, is why does actinic access two databases, while idling? is there a reason for this?

i understand the need for privacy, with people stealing ideas and such, but instead of me simply guessing at what to optimise, is there any way we can know about how (and indeed if) actinic software can speed up somehow?

[zmagyar]

I tried the fastest hard drive, ram and cpu i could find. a 10,000 rpm drive and ddr2 ram. A dual cpu xeon board.

Luckily(?) our developers do not have so high spec PC. Otherwise the application performance may be even worst.

but what i'd really like to know, is why does actinic access two databases

Originally Actinic shipping was designed as a plugin module just like PSPs. The idea was that default Actinic shipping can be replaced by any custom module. That's the reason why we got a separate shipping database. Actually only UPS utilises some of this capability but on long term we may want to change this.

I'm not sure which version did you use for the screenshot but 8.5.0 is significantly better from this POV. Probably you know there was a huge overhaul of shipping in 8.5 and we have introduced a cache for the shipping data during this task. Therefore there is much less access to the shipping DB than the previous versions. This also affects the rendering performance (improved by 5-10% according to our tests).

is there any way we can know about how (and indeed if) actinic software can speed up somehow?

There is no general solution ATM. But there are several tricks and tips on the forum to solve specific issues.

BTW we are aware of the performance problems of v8 and keep trying to improve it by every release. Currently our biggest headache is the design of the user defined property data structure. A major performance improvement can be achieved by its reorganisation. Some bit of this work may be released soon but it is a bit risky change affecting too many areas therefore we can not promise any date or version on this.

[I-CC]

Speed of v8 is an issue without a doubt, but in all honesty can also be put down to the level of customization and conditional programming assigned to the design of the site.

A great strength of v8 is its conditional functions, which allows us to build in all sorts of wonderfull (automatic looking) changes in layouts, icons and many other things, but the processing of these self inflicted conditions add masses to the processing of the database of products.

We have a site which has approach 1,300 products in it, all connected via components, attributes and choices to hidden products for full stock monitoring abilities, and possibly 40 conditions to be read thru and decided upon per product. This means a serious go make a coffee break when ever the site is 'site previewed' or updated (before it even gets to the actual uploading to the site).

The machine we use is a Dual Xeon with Dual Cores, 4MB L2, 4GB RAM, Hard Raid1 RAID drives and it crawls.

On the other hand, basic site with no customization and more importantly no conditions, and it flies through 10,000 products in half the time of the more conditional based 1,300 product site.

Summary: The more we embrace and develop sites using the conditional abilities of v8 (which we love BTW), the slower it will get me thinks and don't see a way around it - apart from a Quad Xeon with Quad Cores and 16GB RAM with a bank of say 16 RAID drives in a RAID 10 config, but hey - a bit early to be adopting that config for Actinic developments hehe

[zmagyar]

Yes, site rendering may slow down significantly when several heavily customised pages need to be generated. I did some c++ profiling on the rendering before v8 release and found the condition evaluation a bit slow. Therefore a condition cache has been added which greatly improved the performance (you can imagine how it was before). Unfortunately the the variables used in the conditions still need to be looked up what is still slow although we are using lot of caches for the value providers. This is a know issue and we are trying to solve it.

Until we find a solution for the most important performance problems I would suggest to move the HTML code to a separate file and get it inluded for the fragments which are repeated on all pages but their content don't depend on the actual page.

[gabrielcrowe]

eek! you linked to a post where I described that technique.

for an instant there, i thought that there was some other gabriel crowe out there having good ideas.

whacky.

[zmagyar]

I guessed it will be familiar to you. :-)