+8
All,
I am having a question regarding the expected performance of a Nintex Workflow that should send +/- 1600 E-mails using the Send Notification action, at a time. Anyone an idea about the expected time frame, performancy issues, best practices...?
Thanks
That's an amazing feet for a workflow. As a consultant I would answer, Yes, but why?
The Send Notification Action will run in the app pool process to deliver the emails. That directly effects the server in the amount of RAM used by the site. The workflow will process one action at a time making 1600 consecutive workflow actions to take a long time, assuming there is some kind of loop or lookup and one action per email. Emails can be grouped by having multiple people in the TO: line obviously. Another thing to consider, if a server or relay sends out that many emails at one time, it could be blocked by an exchange server thinking it could be spam and seen as unusual content.
I'm sorry to question you with Why? But maybe there is more to the situation?
+8
We are implementing a user friendly way to subscribe/unsubscribe on receiving e-mails through SharePoint (aka that a person can decide on which subjects he/she will receive notifications).
There are reasons SP is the way to go, and we are not using the OOTB alerting etc., and it will partially be build custom. We are only deciding or doubting upon letting Nintex take care of the workflow or building it custom. It is not a SP question; but just a Yes/No Nintex question :-)
Ofcourse we should consider, test and keep things in mind like the passing of variables, sending in smaller batches, etc. in Nintex,... But maybe there would be known issues or best practices that could lead our decision or ease the process of doing so.
Guess checking the server possiblities will be one of our key factors.
Ah, I see now. What a neat solution you are trying to build! Nintex will have no problem delivering emails, and the basics of performance improvements would work for any solution. Run mass processing at low traffic times of the day, make sure there is enough RAM on the WFEs.
The biggest performance hit that could be possible when using workflows (any type) is the number of workflows started per minute. One workflow scheduled to run once an hour to query many lists has better performance than many workflows querying one list each started at the same time. When you scale this approach you will see the difference. starting 1000 workflows within minutes of each other will cause many of them to be queued for processing and they will eventually complete. One workflow querying 1000 lists could still be queued eventually, but would be completed faster and less load on the server. But this is how SharePoint manages workflows (2010, or as of 8/14/2014 Nintex 2013 using 2010 workflow mode). This is not to fault how Nintex manages the actions run in a workflow as SharePoint will complete the processing of them.
Hopefully that is useful information. My last question will be, would it be the responsibility of the workflow to determine of what items to alert on and which users to alert? Or would a custom solution handle this processing and Nintex will just be delivering the emails?
+11
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
