I have an issue with my .NET core app hosted on Azure.
Everything works fine in production but the first request after an inactivity period is very very slow (sometimes up to 10-15 seconds).
I don't get where the issue comes from because it didn't happened previously when I was hosting the app on DigitalOcean.
I added below some screenshots of the app on Azure.
Could you please let me know if anyone of you already met a similar issue?
Thanks a lot!
App Service Details
Linux Plan Details
Slow Request Example
App Service Configuration
If you deploy with deployment slots, you can leverage warming-up.
You can even customize the operation: see documentation
This is expected behaviour and happens on local IIS deployments as well.
When you deploy a new version of your site to azure and subsequently make a request to it, it will need to load the resources it depends on into scope which will then be available for the lifetime of that service.
In Production, it might be wise to call the healthcheck pages (which you should already have!) which will alleviate this delay in the case of the resources going out of scope.
I have two an Azure WebApps. Both of them have the "AlwaysOn" option set to true, but even now the WebApps go idle after a bit.
If I don't query the WebApp for a few minutes, the next request I make to the WebApp takes significantly longer. Too long to be acceptable for production.
The WebApp runs a C# ASP.NET MVC 5 project which is my project's API.
Can I do anything to prevent this from keeping on happening?
It seems like having turned off the HTTP to HTTPS rewrite solved the issue. The response is still slow, but much faster than before.
This question is really around analysis - how do I analyze what's causing the problem?
Situation - we have a C# webservice configured through IIS 7.5, and a website in the same intranet domain hitting the webservice with POST and GET methods. Server is windows 2008 r2 64-bit, C# is 4.0. The first call of the day is slow (30-60 seconds), though I have not checked if I try again later in the day is it slow as well. Subsequent calls are 2-3 seconds. When checked using FireFox web console or firebug, the time is spent on "Waiting" for the webservice.
Things I've tried :-
Setting no recycle time for the webservice AppPool
Setting no idle time-out for the webservice AppPool
Setting proxy bypassonlocal = true and usesystemdefault = false in case it's a proxy look up issue
Nothing's worked so far. My thought is that even if it's C# compile to machine code on first run, it shouldn't 'expire' if the AppPool does not time-out or recycle, yet it is slow everyday.
So flat out of options, how do I go about trying to find the source of the problem? Any diagnostics I can run on the server to check what the webservice is doing?
From your description it sounds as if your webservice might be going to sleep given the first call after a period of inactivity is slow and subsequent calls are faster.
I've seen this behaviour occur on many of my .NET IIS applications, can be frustrating to say the least!
This is however, default .NET behaviour, but there are ways of keeping your application awake, especially as of .NET4.
I refer you to the following article as a first step. Give it a go and see if this makes any difference for you:
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
Good luck!
Can I display a specific page while ASP.NET application is still in the process of initialization?
We've got a huge ASP.NET application that takes about 30 seconds to complete its Application_Start() handler after each redeploy or AppDomain restart. Showing a nice self-reloading "temporarily unavailable" page during that time will greatly improve the experience for first users.
I tried to extract the initializer code into a different thread, but it has a lot of dependencies: the HttpContext, Server and several other classes are unavailable from derived threads. The code becomes intervowen and incomprehendable, so I'm looking for a better solution. Maybe some IIS configuration or extension?
Well, since IIS 7.5 you can use Application Initialization for that (http://www.iis.net/downloads/microsoft/application-initialization) that will make it possible to either show a "splash-Screen" or to just pre-start Application-Pools.
Here is the explanation for IIS8: http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization It will work similar with IIS7.5, but there you have to install the module beforehand.
And here a link taken from the comments: http://blogs.msdn.com/b/abhisk/archive/2013/08/16/configuring-application-initialization.aspx
You could load a static html page or page that is not effected by the system startup, then via ajax poll/check something (value, etc) that will only be available once the application starts, this way you could have an animation or some loading information on the page.
I think you're looking for something that is impossible. So you want to create an Application_Start that takes a long time to finish, and you want your application to be responsive during that time. Application_Start is a synchronous event, meaning that not a single request will begin processing before it completes. It is its job after all.
You have to loosen up your requirements somehow. Here are some ideas.
A new HTTP layer
As I said, you cannot run .NET code in your application before Application_Start finishes. But you can run another, different application.
So let's create another application that faces the clients. A reverse proxy or similar. I'm sure there are reverse proxy implementations out there which allow you to do some scripting and solve the issue. On the other hand, I have myself written a simple reverse proxy in C#. When it received an HTTP request, it created an HttpWebRequest and relayed it to another URL. It supported GET and POST, it is working in production for years now. If you are interested, I may be able to share some details about it.
The only thing you have to solve is how your backend application communicates with the frontend. That's easy, you can use WCF, IPC, create a simple 0-byte marker file somewhere, anything at all. When your Application_Start starts, you can create that 0-byte file, and when it completes, you delete it.
Note that many things happen after you shut down your application, restart it, and before the Application_Start runs. IIS initialization can take a few seconds. So instead of the 0-byte marker file, which only has 2 states (exists/not exists), you can expose a simple WCF service, with named pipes for example. It can have 3 states: doesn't respond at all (the application is stopped), it responds that the application is starting up, or it responds that the application is running. This WCF service has to be self-hosted and run in the background, because IIS won't respond obviously.
HTML/JS magic
It is basically the same idea as above. It is easier because you don't have to set up another application, but less flexible. You have to create an HTML landing page for your application and you have to make sure that users don't bookmark any other page. If you can do that, you are in luck. You can use the ideas from the above solution about how your application can communicate with the outside world while it's starting up. You can not use simple web services hosted in IIS, but you can host your own WCF services without any problems (create your own ServiceHost, etc.). Of course, this self-hosted WCF service won't run at the same host:port as your application. But it's pretty easy to expose a JSON service in WCF.
So, in your HTML landing page, you write some JS AJAX code that queries your self-hosted JSON service. If there is no response, you can tell the user that the application is not running at all. If the service says that it is starting up, you can tell that to the user. If the service says that the application is running, then you redirect your user.
This will not work if your users are browsing your site already when you shut it down. See, that's why you need an entirely new layer.
IIS magic
This is a somewhat uncharted territory for me. In integrated mode, .NET is an integral part of IIS, so I think it's hard to work around it. In classic mode, however, .NET is run as an ISAPI extension. So you can, in theory, write a new ISAPI extension that runs before .NET. The bad news is that it has to be written in C/C++. But it is obvious, because like I said, you cannot run .NET code before Application_Start finishes. But IIS is not dead during that time, so solve it at the IIS level. This can get ugly and I'm only 99% sure that it is actually possible.
Refactoring
The above are all workarounds. You really should refactor your code so that Application_Start finishes quickly. It is not meant to be a heavyweight function. There is already a framework for preloading ASP.NET apps. If you tell us why you need HttpContext and Server in your initialization code, we are here to help you with those problems.
I have a few Windows services (all written in C#) that all show the same strange behaviour.
I have them set to delayed auto start so that they get started after the boot (delayed because well they are not critical).
They all host WCF services as parts of Client-Server applications and were installed using WiX if that matters.
I noticed that sometimes they just don't start.
If you look into the Services window fast enough after the OS is ready they have status "Starting". If you then refresh the view they are no longer starting but not "Started" either.
You can then start them manually without any problem whatsoever.
This produces no error messages and no log entrys. And to make it even better this only occurs if the machine has been shut down and turned on again. Reboot works perfectly fine every time (tried it about 20 times on two different machines)
If you set the failure actions to restart the service after failure it seems it will eventually start the service successfully but surely this can not be the ideal solution.
OSs are Windows 7 and WinServer 2008 R2
What am I missing here? Why do they fail to be started automatically(the first time at least)? And why does it make a difference if the computer boots following a reboot or a shutdown?
EDIT:
I was wrong about the failure actions. The did not fix the problem.
EDIT 2:
I have added exception handling around everything to log possible exceptions. But so far no exceptions have been logged.
Might it be the WCF Services take a long time to start? afaik, the windows service has to come up in a certain time (best practices is 30 seconds, technical limit I don't know) to not time out. That could explain why your service is in status "starting" but does not start.
Please see my answer from the duplicate. A windows service typically shouldn't have access to the desktop for security reasons. But it certainly should have a good amount of logging in it. You probably have a race condition. The only thing you could do about this in WiX would be to express a dependency on another service to get the service control manager to wait awhile before starting the service. But it really would be better if your code was more robust. An example would be the OnStart event fire up a background worker process and then return success. The background thread could then keep attempting to host the WCF endpoint and everything do a fair amount of logging in the process.