Apex Sleep: what is CPU penaltySimulate/fake long running REST requestSpin locks with variable time retry backoffsApex CPU Limit ErrorTrigger Error: System.LimitException: Apex CPU time limit exceededHow can I get around Apex CPU time limit error when reassigning lead owner via Apex?Need help with the error : : Apex CPU time limit exceededCPU time out errorApex CPU time limit exceeded with big JSON objectApex CPU time limit exceeded in Apex batch classGetting CPU time errorApex Cpu Limit Exceeded Error in triggerAvoid 'Apex CPU time limit exceeded' with Batch Process

Park the computer

Why is there paternal, for fatherly, fraternal, for brotherly, but no similar word for sons?

Why no parachutes in the Orion AA2 abort test?

Apex Sleep: what is CPU penalty

PhD: When to quit and move on?

What is the addition in the re-released version of Avengers: Endgame?

Bypass with wrong cvv of debit card and getting OTP

How can I effectively map a multi-level dungeon?

Do I need to be legally qualified to install a Hive smart thermostat?

Does a multiclassed wizard start with a spellbook?

In the Seventh Seal why does Death let the chess game happen?

Will a free neutron radiate if it is de-accelerated?

Has chattel slavery ever been used as a criminal punishment in the USA since the passage of the Thirteenth Amendment?

Should I warn my boss I might take sick leave

Can 4 Joy cons connect to the same Switch?

Is it bad to suddenly introduce another element to your fantasy world a good ways into the story?

Taking advantage when the HR forgets to communicate the rules

Data normalization before or after train-test split?

Was Wolfgang Unzicker the last Amateur GM?

Does Evolution Sage proliferate Blast Zone when played?

Can mxd files be under version control?

What units are kpts?

What does the ash content of broken wheat really mean?

Speeding up thousands of string parses



Apex Sleep: what is CPU penalty


Simulate/fake long running REST requestSpin locks with variable time retry backoffsApex CPU Limit ErrorTrigger Error: System.LimitException: Apex CPU time limit exceededHow can I get around Apex CPU time limit error when reassigning lead owner via Apex?Need help with the error : : Apex CPU time limit exceededCPU time out errorApex CPU time limit exceeded with big JSON objectApex CPU time limit exceeded in Apex batch classGetting CPU time errorApex Cpu Limit Exceeded Error in triggerAvoid 'Apex CPU time limit exceeded' with Batch Process






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















As we know (as of V46), there is no apex sleep method. Various workarounds have been proposed such as doing a callout to a service with platform support for sleep but this makes unit testing complicated not to mention callout-dml sequencing to consider.



Simple sleep loops such as this Util.cls method:



public static void sleep(Integer secs) 
Long epochToDate = System.currentTimeMillis();
Long epochStop = epochToDate + (secs * 1000);

while (epochToDate <= epochStop)
epochToDate = System.currentTimeMillis();




run the risk of blowing up CPU limits (10 secs) for the transaction.



What is the CPU penalty of the aforementioned code sample?










share|improve this question






























    1















    As we know (as of V46), there is no apex sleep method. Various workarounds have been proposed such as doing a callout to a service with platform support for sleep but this makes unit testing complicated not to mention callout-dml sequencing to consider.



    Simple sleep loops such as this Util.cls method:



    public static void sleep(Integer secs) 
    Long epochToDate = System.currentTimeMillis();
    Long epochStop = epochToDate + (secs * 1000);

    while (epochToDate <= epochStop)
    epochToDate = System.currentTimeMillis();




    run the risk of blowing up CPU limits (10 secs) for the transaction.



    What is the CPU penalty of the aforementioned code sample?










    share|improve this question


























      1












      1








      1








      As we know (as of V46), there is no apex sleep method. Various workarounds have been proposed such as doing a callout to a service with platform support for sleep but this makes unit testing complicated not to mention callout-dml sequencing to consider.



      Simple sleep loops such as this Util.cls method:



      public static void sleep(Integer secs) 
      Long epochToDate = System.currentTimeMillis();
      Long epochStop = epochToDate + (secs * 1000);

      while (epochToDate <= epochStop)
      epochToDate = System.currentTimeMillis();




      run the risk of blowing up CPU limits (10 secs) for the transaction.



      What is the CPU penalty of the aforementioned code sample?










      share|improve this question
















      As we know (as of V46), there is no apex sleep method. Various workarounds have been proposed such as doing a callout to a service with platform support for sleep but this makes unit testing complicated not to mention callout-dml sequencing to consider.



      Simple sleep loops such as this Util.cls method:



      public static void sleep(Integer secs) 
      Long epochToDate = System.currentTimeMillis();
      Long epochStop = epochToDate + (secs * 1000);

      while (epochToDate <= epochStop)
      epochToDate = System.currentTimeMillis();




      run the risk of blowing up CPU limits (10 secs) for the transaction.



      What is the CPU penalty of the aforementioned code sample?







      apex governorlimits cpulimit






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 9 hours ago









      Adrian Larson

      114k19 gold badges128 silver badges269 bronze badges




      114k19 gold badges128 silver badges269 bronze badges










      asked 9 hours ago









      cropredycropredy

      37.8k4 gold badges45 silver badges132 bronze badges




      37.8k4 gold badges45 silver badges132 bronze badges




















          2 Answers
          2






          active

          oldest

          votes


















          4














          Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs



          But I retried in V46 using this simple testbed:



          Integer delaySecs = 15
          Long start = System.currentTimeMillis();
          Integer cpuStart = Limits.getCpuTime();
          Util.sleep(delaySecs);
          Long stop = System.currentTimeMillis();
          Integer cpuStop = Limits.getCpuTime();
          System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
          System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));


          And got these results (V46)



          delaySecs (input) elapsed (result) cpu (result)
          18 18.003 10.020 (over limit)
          17 17.002 9.304
          16 16.003 9.265
          15 15.004 8.552
          14 14.017 8.001
          13 13.002 7.231
          ...
          10 10.003 5.431
          ...
          5 5.020 2.812
          4 4.002 2.298
          3 3.016 1.724
          2 2.016 1.146
          1 1.033 0.586


          YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis() to be closer 1:1 with CPU time.




          How might this be useful?




          • Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.

          By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.



          You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.






          share|improve this answer






























            1














            Why are you looking to 'sleep' and for how long? Tying up resources in a tight loop does not seem like the ideal solution.



            Something that I did to get a 'job' to run at faster intervals than can be scheduled and to actually run when they are called (versus trying to use the Apex scheduler and hoping that it runs when you want it to) was to make the method a REST endpoint and then have an external program (on an external system) call the REST endpoint (via local cron) on a scheduled basis. Sure, it uses up an API call per invocation, but, because it is a synchronous REST call, Salesforce runs it immediately when you call it (and no matter how often), so it gets around the timing limitations (at least for me it does).



            May not solve your use case, but just tossing the idea out there in case.






            share|improve this answer























            • use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

              – cropredy
              7 hours ago













            Your Answer








            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "459"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f267966%2fapex-sleep-what-is-cpu-penalty%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs



            But I retried in V46 using this simple testbed:



            Integer delaySecs = 15
            Long start = System.currentTimeMillis();
            Integer cpuStart = Limits.getCpuTime();
            Util.sleep(delaySecs);
            Long stop = System.currentTimeMillis();
            Integer cpuStop = Limits.getCpuTime();
            System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
            System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));


            And got these results (V46)



            delaySecs (input) elapsed (result) cpu (result)
            18 18.003 10.020 (over limit)
            17 17.002 9.304
            16 16.003 9.265
            15 15.004 8.552
            14 14.017 8.001
            13 13.002 7.231
            ...
            10 10.003 5.431
            ...
            5 5.020 2.812
            4 4.002 2.298
            3 3.016 1.724
            2 2.016 1.146
            1 1.033 0.586


            YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis() to be closer 1:1 with CPU time.




            How might this be useful?




            • Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.

            By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.



            You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.






            share|improve this answer



























              4














              Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs



              But I retried in V46 using this simple testbed:



              Integer delaySecs = 15
              Long start = System.currentTimeMillis();
              Integer cpuStart = Limits.getCpuTime();
              Util.sleep(delaySecs);
              Long stop = System.currentTimeMillis();
              Integer cpuStop = Limits.getCpuTime();
              System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
              System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));


              And got these results (V46)



              delaySecs (input) elapsed (result) cpu (result)
              18 18.003 10.020 (over limit)
              17 17.002 9.304
              16 16.003 9.265
              15 15.004 8.552
              14 14.017 8.001
              13 13.002 7.231
              ...
              10 10.003 5.431
              ...
              5 5.020 2.812
              4 4.002 2.298
              3 3.016 1.724
              2 2.016 1.146
              1 1.033 0.586


              YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis() to be closer 1:1 with CPU time.




              How might this be useful?




              • Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.

              By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.



              You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.






              share|improve this answer

























                4












                4








                4







                Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs



                But I retried in V46 using this simple testbed:



                Integer delaySecs = 15
                Long start = System.currentTimeMillis();
                Integer cpuStart = Limits.getCpuTime();
                Util.sleep(delaySecs);
                Long stop = System.currentTimeMillis();
                Integer cpuStop = Limits.getCpuTime();
                System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
                System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));


                And got these results (V46)



                delaySecs (input) elapsed (result) cpu (result)
                18 18.003 10.020 (over limit)
                17 17.002 9.304
                16 16.003 9.265
                15 15.004 8.552
                14 14.017 8.001
                13 13.002 7.231
                ...
                10 10.003 5.431
                ...
                5 5.020 2.812
                4 4.002 2.298
                3 3.016 1.724
                2 2.016 1.146
                1 1.033 0.586


                YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis() to be closer 1:1 with CPU time.




                How might this be useful?




                • Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.

                By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.



                You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.






                share|improve this answer













                Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs



                But I retried in V46 using this simple testbed:



                Integer delaySecs = 15
                Long start = System.currentTimeMillis();
                Integer cpuStart = Limits.getCpuTime();
                Util.sleep(delaySecs);
                Long stop = System.currentTimeMillis();
                Integer cpuStop = Limits.getCpuTime();
                System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
                System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));


                And got these results (V46)



                delaySecs (input) elapsed (result) cpu (result)
                18 18.003 10.020 (over limit)
                17 17.002 9.304
                16 16.003 9.265
                15 15.004 8.552
                14 14.017 8.001
                13 13.002 7.231
                ...
                10 10.003 5.431
                ...
                5 5.020 2.812
                4 4.002 2.298
                3 3.016 1.724
                2 2.016 1.146
                1 1.033 0.586


                YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis() to be closer 1:1 with CPU time.




                How might this be useful?




                • Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.

                By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.



                You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 9 hours ago









                cropredycropredy

                37.8k4 gold badges45 silver badges132 bronze badges




                37.8k4 gold badges45 silver badges132 bronze badges























                    1














                    Why are you looking to 'sleep' and for how long? Tying up resources in a tight loop does not seem like the ideal solution.



                    Something that I did to get a 'job' to run at faster intervals than can be scheduled and to actually run when they are called (versus trying to use the Apex scheduler and hoping that it runs when you want it to) was to make the method a REST endpoint and then have an external program (on an external system) call the REST endpoint (via local cron) on a scheduled basis. Sure, it uses up an API call per invocation, but, because it is a synchronous REST call, Salesforce runs it immediately when you call it (and no matter how often), so it gets around the timing limitations (at least for me it does).



                    May not solve your use case, but just tossing the idea out there in case.






                    share|improve this answer























                    • use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                      – cropredy
                      7 hours ago















                    1














                    Why are you looking to 'sleep' and for how long? Tying up resources in a tight loop does not seem like the ideal solution.



                    Something that I did to get a 'job' to run at faster intervals than can be scheduled and to actually run when they are called (versus trying to use the Apex scheduler and hoping that it runs when you want it to) was to make the method a REST endpoint and then have an external program (on an external system) call the REST endpoint (via local cron) on a scheduled basis. Sure, it uses up an API call per invocation, but, because it is a synchronous REST call, Salesforce runs it immediately when you call it (and no matter how often), so it gets around the timing limitations (at least for me it does).



                    May not solve your use case, but just tossing the idea out there in case.






                    share|improve this answer























                    • use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                      – cropredy
                      7 hours ago













                    1












                    1








                    1







                    Why are you looking to 'sleep' and for how long? Tying up resources in a tight loop does not seem like the ideal solution.



                    Something that I did to get a 'job' to run at faster intervals than can be scheduled and to actually run when they are called (versus trying to use the Apex scheduler and hoping that it runs when you want it to) was to make the method a REST endpoint and then have an external program (on an external system) call the REST endpoint (via local cron) on a scheduled basis. Sure, it uses up an API call per invocation, but, because it is a synchronous REST call, Salesforce runs it immediately when you call it (and no matter how often), so it gets around the timing limitations (at least for me it does).



                    May not solve your use case, but just tossing the idea out there in case.






                    share|improve this answer













                    Why are you looking to 'sleep' and for how long? Tying up resources in a tight loop does not seem like the ideal solution.



                    Something that I did to get a 'job' to run at faster intervals than can be scheduled and to actually run when they are called (versus trying to use the Apex scheduler and hoping that it runs when you want it to) was to make the method a REST endpoint and then have an external program (on an external system) call the REST endpoint (via local cron) on a scheduled basis. Sure, it uses up an API call per invocation, but, because it is a synchronous REST call, Salesforce runs it immediately when you call it (and no matter how often), so it gets around the timing limitations (at least for me it does).



                    May not solve your use case, but just tossing the idea out there in case.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 8 hours ago









                    MarcDBehrMarcDBehr

                    3461 silver badge6 bronze badges




                    3461 silver badge6 bronze badges












                    • use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                      – cropredy
                      7 hours ago

















                    • use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                      – cropredy
                      7 hours ago
















                    use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                    – cropredy
                    7 hours ago





                    use case was multiple concurrent queueables doing a Select for Update on a shared resource and getting an UNABLE_TO_OBTAIN_LOCK error; was investigating [this algo(aws.amazon.com/blogs/architecture/…) as mitigation.

                    – cropredy
                    7 hours ago

















                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Salesforce Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f267966%2fapex-sleep-what-is-cpu-penalty%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    ParseJSON using SSJSUsing AMPscript with SSJS ActivitiesHow to resubscribe a user in Marketing cloud using SSJS?Pulling Subscriber Status from Lists using SSJSRetrieving Emails using SSJSProblem in updating DE using SSJSUsing SSJS to send single email in Marketing CloudError adding EmailSendDefinition using SSJS

                    Кампала Садржај Географија Географија Историја Становништво Привреда Партнерски градови Референце Спољашње везе Мени за навигацију0°11′ СГШ; 32°20′ ИГД / 0.18° СГШ; 32.34° ИГД / 0.18; 32.340°11′ СГШ; 32°20′ ИГД / 0.18° СГШ; 32.34° ИГД / 0.18; 32.34МедијиПодациЗванични веб-сајту

                    19. јануар Садржај Догађаји Рођења Смрти Празници и дани сећања Види још Референце Мени за навигацијуу