Product Requirements

S
Badge +1

Hi, we have a SP 2013 Enterprise On Premise Farm (and we're using Nintex WF for SP) that ha:

  • 1 Front End
  • 1 App Server
  • 1 Search Server
  • 1 Database Server

They're well sized (according to MS) but we're having this problem and we believe it's because our servers can't handle what Nintex requires to run (or there's something poorly configured).

We have a Nintex Workflow that, given a parent ID, filters every item in a child list (document library actually) for that parent, breaks inheritance in every item, then assigns exclusive permissions and moves on.

This was working fairly well, until last week, when more records kept coming and the list grew a lil bit (it's sitting around 5k items and growing, nowhere near what MS established as the "limit") and the WF started failing, not every time, but sometimes (around 5%).

Today, when users are using the system intensively the WF is failing almost always, but when we put the site on maintenance, the WF, running it manually, works fine.

We've reviewed the SP log and, among some other cancel issues, we've found the 0x80131530 error to be the most common. We found out that SQL was timing out (thx google), due to, probably, SP throttling resources, still we do not have big querys (inside the WF we always filter by ID) nor large amounts of data (as I said, 5k items tops).

So we're guessing we lack "power" to run the Nintex Workflows, if so, is there a guideline to the hardware requirements we can get? What would be appropriate for this scenario to work? Is there something we're missing/not considering? We're relatively new to Nintex, so please keep an open mind.

Any help whatsoever will be most welcomed...sorry if this is not posted where it should be, I'm guessing dev talk it's the spot, but can be mistaken.

Thanks!

3 replies

S
Badge +7

Not knowing how your workflow is working...

Assuming you have an index on that parent field ID.

What if your workflow is broken into 2. The first workflow will lookup all the relevant ItemID's under your ParentID and then for each itemid updates a Field that triggers the Permission workflow. This permission workflow only runs when  that field is populated with your Trigger and the permission workflow's first action is to pause for 1 min to pass off the load to your timer service. IE things will process in chunks in the background.

You could also tell the 1st workflow to pause, so it's also running under the timer service.

S
Badge +1

Anthony, thx for the response.

We ended up doing something like this via net code, in order to prevent excessive access to our workflows, we established, via a Semaphore, a few amount of resources all users have to share and it's working...better (most WF are completing, still a new problem showed up, which I'm investigating now and will post here if can't find a solution).

Still, we're considering, in order to isolate the problem, your approach (since there're a few related WF we don't want to risk some error while updating/upgrading, but it's a pretty solid idea)

J
Badge +1

Regardless of what you end up choosing, do a test where you kick off the problem workflow and then use Perfmon or the Task Manager on your WFE server to see what the resources are doing. If the CPU is maxed out then you know you need more power.

 

If not, then you have a resource conflict and adding more power (servers or CPUs etc) won't help you. You will need to space things out using pauses and multiple workflows.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings