We need to speed up getting items to staging (WCM scaleing)

[kmartino]

We have opened a ticket on this, but wanted to ask the Alfresco user community what they do in similar circumstances.

The short of it is that workflows are taking longer and longer to execute after adding just a few hundred content items or having more than 3 or so users adding content and submitting it through the system.  

This, in turn, leads to items appearing in search after a considerable drag, and for scheduled published jobs taking longer than they should. 

Much of the content is for direct publish and does not require review or scheduling, but we are submitting it through workflow anyway.

All of this content is uploaded via custom webscripts that manipulate content based upon business rules, generate renditions, and then submit workflows to push content to staging.

We're attempting to address this a few ways - two of which I want to share

1. Reducing the number of workflows – by bundling related content together into singular workflow jobs (just good practice - we're on our way to doing this).
2. Exploring the effects of changing lucene indexing from serial to asynchronous (probably not desired since we want content to appear in search *sooner* rather than later).
3. Exploring if we can have workflows run parallel for the content that has unique paths
4. Exploring if we can submit content to staging without a workflow for the content that has unique paths

On item 4  we have attempted to use SandboxService's submitList() to avoid using a workflow, but apparently it still issues a workflow. 

Do workflows in WCM execute serially (that's what we are observing btw) ? And if so does that imply a relatively small number of content items that can published in a timely manner from it?

For example if a workflow/index job takes 30 seconds (best case scenario we see), and you have 5 users attempting to publish 5 items a piece in quick succession:

(Users*Items)(WF)=12 minutes of jobs in flight.

User 6 comes along to do the same and now needs to wait *at least* 12 1/2 minutes before seeing their content flow through the system (get on staging, get indexed, and be available for others to see/edit/etc?)

In each case the content item is uniquely pathed within Alfresco, and does not require review approval workflow. 

We are using Enterprise 3.1.1 on Solaris, publishing to a FSR.

Thanks for your experience and suggestions,

Karl

[tommorris]

Hi there.

What hardware is your alfresco/solaris running on? Certain Sparc hardware architectures may experience a massive slow-down. Try running on a similarly powered Intel architecture and compare your two performance benchmarks.

We definitely experience much better performance issuing batches of submissions (somewhere between 50 to 100).

Yes, all the workflows do run in a sequential serial fashion, to ensure non-concurrent mutable operations to any one sandbox. You can change also the polling frequency that this JBPM thread executes (I think it may have changed from 2 mins to 30 secs or something recently - I'd need to check)

I would recommend loading up a new temporary sandbox with a batch of files, and then submitting it to the workflow, which destroys it once it has finished the merge with the staging sandbox. Immediately after triggering the submission, you're safe to create another temporary sandbox, start filling that one with new files (or changes), so that process of loading batches can be performed in parallel.

Other performance tips:
Switch off metadata extraction on your target ASR (if you happen to use either).
Keep you folder structure heavily segmented (not too many files in any one folder-node).
Operate your search webscripts as 'System' to bypass securty checks.

Tom
http://www.ixxus.com