Understanding App Insights end to end for occassional long response times












1















Background: I have an ASP.NET Core App and have an API method that takes a file name of a blob that the frontend has uploaded to Azure Blob. It then needs to create a thumbnail version of the blob and return the name of the newly uploaded thumbnail Blob. Sometimes, for exactly the same file size it can take up to 40 seconds to complete. Mostly, it's around 400ms.



Below is the end to end from App Insights, I have a few things I don't understand:



1) The request duration is 37.5 s but yet the other operations add up to nowhere near this time



2) Why are there calls to master db? We are using EF6 with multiple contexts



3) The app is using an Azure App Service and SQL Azure. I don't understand why the response time is so inconsistent.



Any help would be much appreciated!
enter image description here










share|improve this question


















  • 1





    Code of the relevant API controller action would be useful here.

    – Brendan Green
    Nov 21 '18 at 4:59
















1















Background: I have an ASP.NET Core App and have an API method that takes a file name of a blob that the frontend has uploaded to Azure Blob. It then needs to create a thumbnail version of the blob and return the name of the newly uploaded thumbnail Blob. Sometimes, for exactly the same file size it can take up to 40 seconds to complete. Mostly, it's around 400ms.



Below is the end to end from App Insights, I have a few things I don't understand:



1) The request duration is 37.5 s but yet the other operations add up to nowhere near this time



2) Why are there calls to master db? We are using EF6 with multiple contexts



3) The app is using an Azure App Service and SQL Azure. I don't understand why the response time is so inconsistent.



Any help would be much appreciated!
enter image description here










share|improve this question


















  • 1





    Code of the relevant API controller action would be useful here.

    – Brendan Green
    Nov 21 '18 at 4:59














1












1








1








Background: I have an ASP.NET Core App and have an API method that takes a file name of a blob that the frontend has uploaded to Azure Blob. It then needs to create a thumbnail version of the blob and return the name of the newly uploaded thumbnail Blob. Sometimes, for exactly the same file size it can take up to 40 seconds to complete. Mostly, it's around 400ms.



Below is the end to end from App Insights, I have a few things I don't understand:



1) The request duration is 37.5 s but yet the other operations add up to nowhere near this time



2) Why are there calls to master db? We are using EF6 with multiple contexts



3) The app is using an Azure App Service and SQL Azure. I don't understand why the response time is so inconsistent.



Any help would be much appreciated!
enter image description here










share|improve this question














Background: I have an ASP.NET Core App and have an API method that takes a file name of a blob that the frontend has uploaded to Azure Blob. It then needs to create a thumbnail version of the blob and return the name of the newly uploaded thumbnail Blob. Sometimes, for exactly the same file size it can take up to 40 seconds to complete. Mostly, it's around 400ms.



Below is the end to end from App Insights, I have a few things I don't understand:



1) The request duration is 37.5 s but yet the other operations add up to nowhere near this time



2) Why are there calls to master db? We are using EF6 with multiple contexts



3) The app is using an Azure App Service and SQL Azure. I don't understand why the response time is so inconsistent.



Any help would be much appreciated!
enter image description here







asp.net entity-framework azure asp.net-core azure-storage-blobs






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 '18 at 22:11









PaulPaul

1,62263049




1,62263049








  • 1





    Code of the relevant API controller action would be useful here.

    – Brendan Green
    Nov 21 '18 at 4:59














  • 1





    Code of the relevant API controller action would be useful here.

    – Brendan Green
    Nov 21 '18 at 4:59








1




1





Code of the relevant API controller action would be useful here.

– Brendan Green
Nov 21 '18 at 4:59





Code of the relevant API controller action would be useful here.

– Brendan Green
Nov 21 '18 at 4:59












2 Answers
2






active

oldest

votes


















1














I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).



I solved the issue by configuring health checks that occasionally perform requests to the app.



Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.



Hope it helps!






share|improve this answer































    0














    1.



    The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.



    A dependency being another call that sends its run-time to the application insights.
    In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.



    So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.



    You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.



    2.



    Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).



    3.



    Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).






    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      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: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      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%2fstackoverflow.com%2fquestions%2f53402378%2funderstanding-app-insights-end-to-end-for-occassional-long-response-times%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









      1














      I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
      As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).



      I solved the issue by configuring health checks that occasionally perform requests to the app.



      Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.



      Hope it helps!






      share|improve this answer




























        1














        I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
        As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).



        I solved the issue by configuring health checks that occasionally perform requests to the app.



        Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.



        Hope it helps!






        share|improve this answer


























          1












          1








          1







          I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
          As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).



          I solved the issue by configuring health checks that occasionally perform requests to the app.



          Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.



          Hope it helps!






          share|improve this answer













          I've noticed multiple time that the first request after an application is deployed to Azure or after a long period that no requests were made to the application, it takes significantly longer to get a response.
          As far as I remember it was related to start-up time of the site (if you're using an App Service on Windows based underlying VM it still uses IIS as a reverse proxy).



          I solved the issue by configuring health checks that occasionally perform requests to the app.



          Also, in addition to Application Insights (which logs information only after the application has started), you can try the tools listed here to see more information.



          Hope it helps!







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 21 '18 at 7:47









          Itay PodhajcerItay Podhajcer

          1,9871412




          1,9871412

























              0














              1.



              The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.



              A dependency being another call that sends its run-time to the application insights.
              In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.



              So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.



              You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.



              2.



              Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).



              3.



              Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).






              share|improve this answer




























                0














                1.



                The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.



                A dependency being another call that sends its run-time to the application insights.
                In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.



                So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.



                You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.



                2.



                Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).



                3.



                Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).






                share|improve this answer


























                  0












                  0








                  0







                  1.



                  The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.



                  A dependency being another call that sends its run-time to the application insights.
                  In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.



                  So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.



                  You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.



                  2.



                  Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).



                  3.



                  Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).






                  share|improve this answer













                  1.



                  The way the request timeline is displayed gives you only the time-span for the whole request (37.5s) and the individual time-spans for each dependency.



                  A dependency being another call that sends its run-time to the application insights.
                  In your example each call to the database is automatically tracked as a dependency. The code running after each database call is not though.



                  So e.g. requesting a database entry which takes 200ms and then issuing a Thread.Sleep of 2 seconds and requesting another database entry which takes 300ms would result in a 2 second gap between the two database-call dependencies which will each be listed with 200/300ms respectively.



                  You can use TelemetryClient.TrackDependency to wrap parts of your own code into its own dependency. This way you will see your own code as an entry on the request timeline.



                  2.



                  Depending on your EntityFramework database-initialisier EF will connect to the master db on context creation. (E.g. to create the database if it does not exist).



                  3.



                  Try tracking your own code to find out what parts of it are slow. EF has a few performance issues to consider, try to understand the performance caveats of the libs you use. If your calls are inconsistently slow it might be an issue with resources being over-utilized or caches being emptied too early (like for EF warm vs. cold queries).







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 20 at 9:42









                  GaussZGaussZ

                  576321




                  576321






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • 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%2fstackoverflow.com%2fquestions%2f53402378%2funderstanding-app-insights-end-to-end-for-occassional-long-response-times%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

                      MongoDB - Not Authorized To Execute Command

                      in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith

                      Npm cannot find a required file even through it is in the searched directory