0

I'm having an issue where the first request to my ASP.net API is slow.

So it's not the first user to make a request, it's the first request from any device to the server that's slow. Once the first request by that device has been made then the rest of the requests from that device are quick for the rest of the day up until the next day. Once it's the new day then again that devices first request is slow.

I don't think it's the server sleeping because like I said above it's the first request from every device.

Just to give an example for clarity.

If I go on my computer and make a request to the API it's going to be slow for my first request. If another person next to me makes a request to the same API his/her first request will also be slow even though I made a request first (basically waking up the server).

Another thing is that this happens when I test the API on my local machine too. The first request is about 18s then if I restart it on my local then once again the first request is slow.

Does anyone have any ideas as to what's happening?

.Net Framework 4.6.1 We use Azure too.

  • 1
    possible duplicate: https://stackoverflow.com/questions/13386471/fixing-slow-initial-load-for-iis – jazb Oct 15 '21 at 06:14
  • 1
    I suppose that you are sending a request from a web app? If so, please use browser console and look at the Timing tab in network monitor panel. You can find there an information about how long each stage of a network request took, with a more detailed. It can help to locate a bottleneck. – 1_bug Oct 15 '21 at 06:15
  • @1_bug I have used the network monitoring tool to view what happening what I saw was the request time is less that a second but the waiting(TTFB) takes all the time about 16seconds – ID10T_E330r Oct 15 '21 at 06:33
  • @Jazb I've seen questions like this but I'm not sure it's the same because they say it's the very first user request. My situation is for every new device (I suppose you could say every new use). The server isn't sleeping either. We have set the always-on feature on the Azur service to try and stop the API from sleeping. – ID10T_E330r Oct 15 '21 at 06:38

2 Answers2

1

Most likely the device is qualifying the domain and caching the headers during preflight. This is normal for most web API's. The client caches details about the connection in order to make future requests much faster. You could also look into gzipping your requests to compress your payload.

I have found .net 4 web apis to run slower than .net core when making first requests. But .net core can sometimes take 5-6 seconds as well

Mark Barton
  • 847
  • 6
  • 15
0

Not knowing your application there could be many reasons. One reason could be that you are storing a fairly large object in the cache on the client side. The first request to the API might ask for all the information to populate this model (in its entirety), which could be of significant size. After deserialization of the requested object on the client side, the subsequent requests might be of significantly smaller payload sizes, only to update the model on the client side. Hence, the reason for the subsequent requests being faster. After a session is ended and restarted on the client side (e.g. by closing the browser), the client side cache is cleared and the model needs to be loaded up again, perhaps being the reason why you are always observing the long loading time for the first request.

Possible solutions here would be:

  1. To investigate whether the initial payload (normally a json string) between the server and client can be reduced by removing redundant information/properties from it.
  2. To see if you can compress the data coming from the server by using some compressor if you have access to the source code of the API. (e.g. https://learn.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-5.0)

This is only speculation, based on the information you provided, but might be something to investigate.

Francois Louw
  • 143
  • 2
  • 3
  • 13
  • I don't think it's client-side. The Waiting(TTFB) is from what I've read, the Time Till First Byte which to me means it's the time the client is waiting for a response from the server. I might very well be wrong but that's just my understanding of it. – ID10T_E330r Oct 15 '21 at 06:51
  • Yes. It could be. As I said, it is mere speculation from my side. Do you have an indication of how large your first requested string is? – Francois Louw Oct 15 '21 at 06:58
  • ok yeah I get you. The first request is generally a login request which is only a couple kb as its a username and password. – ID10T_E330r Oct 15 '21 at 07:02