locked
Time to first byte taking ages RRS feed

  • Question

  • User1738843376 posted

    Hello,

    I'm developing a website on VB.net Webforms and AJAX, and have recently encountered a very strange and annoying issue:

    When opening a product detail page (formed by a very simple MasterPage and an ASPx), i'm performing 3 AJAX requests via JQuery to fill out some data on the page.

    These requests are performed as a queue, starting with the LoadProductDetails call, then a LoadShoppingCartDetails call, and finally LoadOtherProducts. These requests are made using the $.when ... done() method, so that one only starts when the prior is completed.

    The strange thing is that, on my local machine, the page always loads instantaneoulsy, taking under 500ms to load, while both on the staging server and the production server, sometimes is takes the same 500ms, other it rises to a ridiculous 16s.

    When inspecting the page load with the Dev Toolbar, under the Network tab, i can see that almost all of these 16 seconds are listed as Time To First Byte.

    This delay happens, regardless of what combination of these 3 functions named earlier is being called. I can take any of them from the page, and the loading time persists.

    After researching the web for such behaviour, i came across some posts that stated it might be an issue with the usage of the Session object inside the AJAX called WebMethods, so i rebuild all my Shopping Cart, which was being saved to the session object while not finalised, and instead, i now save the cart to the database, storing a cookie on the client side containing the reference to the shopping cart on the database, thus, eliminating the usage of the Session object.

    Despite all the efforts, the issue persists, which makes the website pretty much useless, since nobody it their perfect state of mind waits 16 seconds for a website to load, as you might expect.

    The page, after images and resources are loaded, amounts to around 1.2mb, while the AJAX calls are about 7.4kb for the LoadProductDetails , 360b for the LoadShoppingCartDetails  and 33kb for the LoadOtherProducts, so as you can see, its a very low amount of data in the transactions.

    I'm using Prefix on my local machine, so i can also tell you that the LoadProductDetails  makes 21 calls to the DB, taking 108ms to complete them, the LoadShoppingCartDetails performs a single query to the SQL database, taking 12ms and the LoadOtherProducts completes 82 calls to the database, taking 96ms in the process.

    The website runs on ASP.net 4.6.1 and SQL Server Express 2016.

    Are there any ideas of what might be happening and how to resolve it?

    All input is appreciated, as i'm getting desperate with this situation while bumping my head on the wall for more that 2 days now.

    Thanks in advance

    Monday, December 30, 2019 7:27 PM

Answers

  • User1738843376 posted

    Hi Paul,

    Thanks a lot for your insight.

    I'm using a dedicated server, where i host all my websites.

    After your post, i considered if this was a result of me using asp.net websites, and not webapplications, since websites are build on the fly on the first run, while webapps are pre-built, supposedly enhancing the performance. 

    This, however, could not be the case, since i was frenetically refreshing the page, and sometimes it was immediate, other it took the 16secs. This behaviour sent me looking for different perspectives.

    While banging my head on the wall, i eventually came up with an idea, which was to remove all the debugs i had implemented via Log4Net that i was tracing through Prefix.

    Once i removed all the debugging tracings (left only the ones that log fatal and error levels), the website no longer took the eternity it was taking to  load, and started to consistently respond under a second. 

    Bottom line, for future reference, always remove all logging when finished the development, even if you disconnect the functionality via log4net.config.

    Again, thanks for the time you took for answering my distress signal. Even though it did not solve it, it eventually forced me in the right direction.

    Happy new year!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, January 2, 2020 4:06 PM

All replies

  • User303363814 posted

    Are you using a shared hosting facility?

    It is quite common for shared hosting to 'run-down' processes which are not being used (they are recovering resources so they can support more customers and make more money).  So it is normal to see the first hit to a web site take a long time as various pieces of infrastructure start up.  Once all required processes are running then subsequent requests are serviced quite quickly from already running processes/caches etc.  If there is no activity for a period of time (ask your hosting company for the time they use) then processes are allowed to exit.  The next access will again occur the startup overhead.

    If you are using a database server, which may be on a separate machine on the network then the same procedure will occur on that machine.  If you are using web services on other machines then the same procedure may occur.  If you wait for one piece of work to complete before starting the next one then you are accumulating the delays.  Doing things in parallel may give some relief but, in my experience, is not generally worth the bother.

    The good news is that if your web site is popular so that people are visiting all the time then the various behind-the-scenes processes will not get to be idle and so not terminated by the hosting company.

    FWIW - on my website I have a background job which runs once every two minutes which does a simple database query to keep the database server 'alive'.  This seems to fix most startup delay problems.  You will need to work out which of your particular startup activities is taking up the time and work out how to fix that one.

    Monday, December 30, 2019 11:07 PM
  • User1738843376 posted

    Hi Paul,

    Thanks a lot for your insight.

    I'm using a dedicated server, where i host all my websites.

    After your post, i considered if this was a result of me using asp.net websites, and not webapplications, since websites are build on the fly on the first run, while webapps are pre-built, supposedly enhancing the performance. 

    This, however, could not be the case, since i was frenetically refreshing the page, and sometimes it was immediate, other it took the 16secs. This behaviour sent me looking for different perspectives.

    While banging my head on the wall, i eventually came up with an idea, which was to remove all the debugs i had implemented via Log4Net that i was tracing through Prefix.

    Once i removed all the debugging tracings (left only the ones that log fatal and error levels), the website no longer took the eternity it was taking to  load, and started to consistently respond under a second. 

    Bottom line, for future reference, always remove all logging when finished the development, even if you disconnect the functionality via log4net.config.

    Again, thanks for the time you took for answering my distress signal. Even though it did not solve it, it eventually forced me in the right direction.

    Happy new year!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, January 2, 2020 4:06 PM