Scheduled Script Best Practices

The following are best practices for scheduled scripts. Also see Scheduled Script Handling of Server Restarts.

General

  • Scheduled deployments and Not Scheduled deployments are executed from the same processor pool. Keep this in mind as you deploy multiple scheduled scripts because the amount pending script instances is the ultimate bottleneck for scheduled script execution throughput.

  • The number of Not Scheduled deployments to create should depend on the anticipated number of simultaneous calls you expect to make to this script and the approximate execution time of the script. A general rule of thumb is to create twice as many deployments as the total number of simultaneous calls you anticipate for this script.

  • Although there is no restriction on the number of Not Scheduled scripts that can be placed into the processing pool, too many pending scripts may create a backlog and compromise system performance. Because only one script can be run in a processor at a time, you should not overload the system.

  • If you want to deploy scheduled scripts that are scheduled to run hourly on a 24 hour basis, the following sample values should be set on the Script Deployment page:

    • Deployed = checked

    • Daily Event = [radio button enabled]

    • Repeat every 1 day

    • Start Date = [today's date]

    • Start Time = 12:00 am

    • Repeat = every hour

    • End By = [blank]

    • No End Date = checked

    • Status = Scheduled

    • Log Level = Error

    • Execute as Role = Set to Administrator

    If the Start Time is set to any other time than 12:00 am (for example it is set to 2:00 pm), the script will start at 2:00 pm, but then finish its hourly execution at 12:00 am. It will not resume until the next day at 2:00 pm.

  • When possible, schedule your deployments during the hours of 2 AM to 6 AM PST. Deployments scheduled for submission during the hours of 6 AM to 6 PM PST may not run as quickly due to high database activity.

Deployments that continue to use queues

  • If you do not have an account with SuiteCloud Plus, all Scheduled deployments and Not Scheduled deployments that continue to use queues are executed from the same queue. If you deploy multiple scheduled scripts that continue to use queues, your queue size is the ultimate bottleneck for scheduled script execution throughput. For additional information, see Scheduled Script Deployments that Continue to Use Queues.

  • Although there is no restriction on the number of Not Scheduled scripts that can be submitted to SuiteCloud Processors, too many waiting scripts may create a backlog and compromise system performance. Because only one script can be run at a time, you should not overload the system.

  • Although there is no restriction on the number of Not Scheduled scripts that can be placed into the processing pool, too many pending scripts may create a backlog and compromise system performance. Because only one script can be run in a processor at a time, you should not overload the system.

Scheduled script vs Map/Reduce script

  • In general, you should use a map/reduce script rather than a scheduled script for any scenario where you want to process multiple records, and where your logic can be separated into relatively lightweight segments. However, a map/reduce script is not as well suited to situations where you want to enact a long, complex function for each part of your data set.

  • Like a scheduled script, a map/reduce script can be invoked manually or on a predefined schedule. However, map/reduce scripts offer several advantages over scheduled scripts. One advantage is that, if a map/reduce job violates certain aspects of NetSuite governance, the map/reduce framework automatically causes the job to yield and its work to be rescheduled, without disruption to the script. However, be aware that some aspects of map/reduce governance cannot be handled through automatic yielding.

  • With SuiteScript 2.x scheduled scripts, you cannot set recovery points and you do not have the ability to yield. If you need to process a large amount of data or a large number of records, use a map/reduce script instead. The map/reduce script type has built in yielding and can be submitted for processing in the same ways as scheduled scripts.

For information about map/reduce scripts, see SuiteScript 2.x Map/Reduce Script Type.

Related Support Articles

Related Topics

General Notices