question Maximum number of transactions in Service Management forum

Maximum number of transactions

bonsai — Mon, 17 Jan 2022 14:12:21 GMT

※Paris version

When I checked the transactions when I executed the following script, I could only execute up to 8 transactions at a time.

function scripte() {
    //ScheduleJob

    sleepe(12000);

    function sleepe(a) {
        var startMsec = new Date();
        while (new Date() - startMsec < a);
    }
}
var sched = new ScheduleOnce();
sched.script = '(' + scripte + ')();';
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();
sched.schedule();

Originally I want 12 transactions to be launched.
Can this be adjusted from 8 to 12?

Re: Maximum number of transactions

Appli — Mon, 17 Jan 2022 16:43:13 GMT

Hi, I believe the max number of workers (8) per node is hardcoded in background scheduler and could not be changed. But please raise a support case for ServiceNow asking them to confirm the same.

Hope it helps

Re: Maximum number of transactions

bonsai — Mon, 17 Jan 2022 22:30:27 GMT

thank you for your answer. Is per node a unit to be executed by one script? Is it possible to execute 8 or more transactions by calling this script recursively?

Re: Maximum number of transactions

Tony Chatfield1 — Mon, 17 Jan 2022 23:49:59 GMT

Hi, as Appli indicated a node has 8 configured 'workers' and it will also have a 'burst worker' which may activate under specific conditions to handle core functionality.

https://community.servicenow.com/community?id=community_article&sys_id=e61d22e5dbd0dbc01dcaf3231f9619fd

Can you clarify your business requirement\intended objectives?
Why do you require 12 concurrent transactions?

Re: Maximum number of transactions

bonsai — Tue, 18 Jan 2022 00:11:46 GMT

The following is an example of an "incident" table, but I want to execute transactions for the number of records in a specific table at the same time.

function scripte() {
    //ScheduleJob

    sleepe(12000);

    function sleepe(a) {
        var startMsec = new Date();
        while (new Date() - startMsec < a);
    }
}
var sched = new ScheduleOnce();
sched.script = '(' + scripte + ')();';

var grInc = new GlideRecord('incident');
grInc.query();
while (grInc.next()) {
	sched.schedule();
}

I'd like to know more about'burst worker', but the following text on the page you told me adjusts the property numbers. Which table record does this adjust?
I heard that the "priority" field is missing in the "sys_trigger" table.

Configure scheduled jobs to use 'burst' scheduler workers

For instances running Dublin or newer releases, you can insulate against "clogged up" scheduler worker queues by setting the 'priority' field on the sys_trigger entry for the scheduled job to be "25". By making this change, you can ensure that core jobs such as event processors, SMTP sender, POP reader and SMS sender get triggered in a timely fashion. Should all the scheduler workers be busy with other jobs, an "important" job which is more than 60 seconds past due will spawn a 'burst scheduler worker' and execute in parallel to the core 8 schedulers on the node. This is taken care of Out Of Box from the Geneva release and onwards. Caution: This is good insulation, but should not be used as an excuse not to address the root causes of the other "long running" or "high volume" scheduled jobs.

Re: Maximum number of transactions

Tony Chatfield1 — Tue, 18 Jan 2022 00:32:00 GMT

Hi, I would not recommend any changes to worker\burst functionality unless you have an exceptionally good understanding of the platform, as changes of this nature may impact platform performance\responsiveness and also it's stability.

I have not seen documentation that covers off how an instance allocates individual jobs between nodes and their workers, but based on observations I think you may find that there is some attempt by the instance to allocate similar jobs to a node\worker, so that they are processed sequentially (and perhaps this is more efficient use of resource).

Perhaps you could explain why you need to execute multiple jobs on 1 table concurrently?
Even if these jobs started processing concurrently, the outcome IE updates to other tables, generation of other jobs, sysevents, notifications etc etc, would eventually end up in a sequential\queue somewhere...within the instance or externally.

Re: Maximum number of transactions

bonsai — Tue, 18 Jan 2022 03:15:06 GMT

By the way, is the maximum number of concurrent executions 8 times for paid instances instead of free development instances?
Is there a difference such as an increase in the number of nodes that can be executed simultaneously in the case of a fee?

Re: Maximum number of transactions

Hitoshi Ozawa — Sun, 23 Jan 2022 14:00:18 GMT

If performance is an issue and money isn't a problem, may be switch to using Oracle. The default is MySQL/MariaDB.

I've read several times about ServiceNow supporting Oracle database but I can't find the page right now.

Re: Maximum number of transactions

Hitoshi Ozawa — Sun, 23 Jan 2022 14:11:14 GMT

Following thread provides information on the standard ServiceNow instance. Anything beside the standard default should be discussed with ServiceNow sales reps instead of here. I think it's all going to depend on money.

8 background schedules is the standard for ServiceNow paid production instance.

https://community.servicenow.com/community?id=community_question&sys_id=bb8c8fa5db9cdbc01dcaf3231f9619a8

Re: Maximum number of transactions

Hitoshi Ozawa — Sun, 23 Jan 2022 16:29:36 GMT

The default is 8 background jobs per node. Customers can buy more nodes to increase number of concurrent background jobs.

Also, it's the total of 8 concurrent background jobs. Background jobs are not just jobs created by scheduler but other jobs such as Discovery, email processing, and workflow. That is, if some other such as those are running, there would be less than 8 user scheduled background jobs times number of nodes.

It's also "background" jobs. End users are still able to click on "Order"/"Submit" button and have the form processed while these background jobs are running.

Furthermore, 8 background jobs are the number set by ServiceNow. It's not the limitation set by Java container such as Tomcat.

Finally, if running database operations in a background job, there's also number of database connections.

There's a need to balance between foreground , background, and database to obtain a maximum throughput from an instance.