I have a WebAPI application running on Azure WebSites. It is running in Basic mode and I have the option to make it "Always On". There seems to be conflicting information online about what this means exactly. I know the effect, but the "how" matters a lot here. In particular, does something automatically hit an endpoint in my application periodically? If so, can I control the endpoint it hits?
As I mentioned, it is a Web API application and the default route does non-trivial work and results in a notable amount of outbound traffic and it will also result in items being placed onto a work queue that will eventually be processed. I want the application always on (no cold start times) but I don't want some service making requests of application.
As soon as your Azure Website is marked as AlwaysOn, your site root will be hit within a few seconds. We also make sure your site is up and running on all the workers (if you have configured auto scale option or such). After that, if the worker process crashes, alwaysOn makes sure that it comes back up.
You cannot control the endpoint that it hits.
Related
By looking at my Pingdom reports I have noted that my WebSite instance is getting recycled. Basically Pingdom is used to keep my site warm. When I look deeper into the Azure Logs ie /LogFiles/kudu/trace I notice a number of small xml files with "shutdown" or "startup" suffixes ie:
2015-07-29T20-05-05_abc123_002_Shutdown_0s.xml
While I suspect this might be to do with MS patching VMs, I am not sure. My application is not showing any raised exceptions, hence my suspicions that it is happening at the OS level. Is there a way to find out why my Instance is being shutdown?
I also admit I am using a one S2 instance scalable to three dependent on CPU usage. We may have to review this to use a 2-3 setup. Obviously this doubles the costs.
EDIT
I have looked at my Operation Logs and all I see is "UpdateWebsite" with status of "succeeded", however nothing for the times I saw the above files for. So it seems that the "instance" is being shutdown, but the event is not appearing in the "Operation Log". Why would this be? Had about 5 yesterday, yet the last "Operation Log" entry was 29/7.
An example of one of yesterday's shutdown xml file:
2015-08-05T13-26-18_abc123_002_Shutdown_1s.xml
You should see entries regarding backend maintenance in operation logs like this:
As for keeping your site alive, standard plans allows you to use the "Always On" feature which pretty much do what pingdom is doing to keep your website warm. Just enable it by using the configure tab of portal.
Configure web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/
Every site on Azure runs 2 applications. 1 is yours and the other is the scm endpoint (a.k.a Kudu) these "shutdown" traces are for the kudu app, not for your site.
If you want similar traces for your site, you'll have to implement them yourself just like kudu does. If you don't have Always On enabled, Kudu get's shutdown after an hour of inactivity (as far as I remember).
Aside from that, like you mentioned Azure will shutdown your app during machine upgrade, though I don't think these shutdowns result in operational log events.
Are you seeing any side-effects? is this causing downtime?
When upgrades to the service are going on, your site might get moved to a different machine. We bring the site up on a new machine before shutting it down on the old one and letting connections drain, however this should not result in any perceivable downtime.
I am working on windows azure cloud service. First time when i click on login button it takes 6 to 7 seconds but after sometime when i click on same login button it takes 2 seconds. I am not able to understand why it is happening so though the server side code is same for both processing but subsequent calls are quiet faster than first call ?.
"First-hit" delay is very common with ASP.NET applications. There is the overhead of JIT compilation, and various "pools" (database connections, threads, etc) may not be initialized. If you have an ASP.NET Web Forms application, each .aspx page is compiled the first time it is accessed, not when the server starts up. Also the various caching mechanisms (server or client) that make subsequent requests faster are not initialized on that first hit. And on the very first hit, any code in Application_Start will be run, setting up routing tables and doing any other initialization.
There are various things you can do to prevent your users from seeing this delay. The simplest is to write some kind of automated process that hits every page and run it after deploying a new release. There are also modules for IIS that will run code ahead of the Application_Start, when the site is actually deployed. Search for "ASP.NET warmup" to find those.
You may also experience delays after a period of inactivity, if your ASP.NET App Pool is recycled - this resets a bunch of things and causes start-up code to be run again on the next request. You can ameliorate this effect by setting up something to ping a page on your site frequently so that if the app pool is recycled it is warmed up again automatically, instead of on the next actual user request. Using an uptime monitoring service will work for this, or a Scheduled Task within the Azure ecosystem itself.
we are evaluating Azure right now and I really like the azure web sites, especially because of the very easy and fast deployment, which is helpful in our current situation where we make a lot of tests.
We have some in-memory-caches for information that is accessed very often per request like text-strings for multi-language-support and configuration settings edited by the site administrator. I would like to have a system where each instance of the web site has a copy of this cached data, but i need to send flush-events for cache invalidation to all instances when some settings are changed by the administrator. I guess that the azure service bus is perfect for this with the publish-subscribe-model, but I dont want to pay 3€ per instance just for sending some messages around.
Is there an option to open an individuell endpoint per instance, where I can a wcf-service for example?
This is no good way to direct a request at a specific instance of a Windows Azure Web Site that I'm aware of. The load balancer for Web Sites is defaulted to use sticky sessions (which you can turn off), but there isn't a way to force the request going in to be directed to once instance of a web site over another.
You could look at the Service Bus as you mentioned with a Topic and several subscriptions, which is indeed an option, but as you point out it does cost something. I'm interested in where you got the calculation for the amount though. Brokered messaging is charged per message (with "empty requests also being included"). If you had an instance checking once a minute for a month it's only about 43,000 calls. You can get 1 million calls for a US Dollar. With the long polling that Service Bus has in the managed client you end up with fewer "empty" calls than standard polling.
Another option is to simply use a different polling mechanism. In this case you are just wanting an indicator that you should, or should not flush the cache. You could put a text file in BLOB storage that contains a cache current version value. This could be whatever you want, a number, a guid, doesn't matter. Each instance would then from time to time check this BLOB file. If the value in the file is different than what they last saw they refresh their cache. Then they hold on to the new cache version value for their next call. You can either set this up as a WebJob on a schedule or do your own background polling.
Finally, there is the Windows Azure Cache Service (preview) which is usable by Web Sites, but that would cost additional and, if you really are caching the exact data on all instances, wouldn't be as efficient. It would give you the ability to deal with the cache service directly though, independent of the instances that are using it, allowing you to reset and such as you needed, on demand, in one fell swoop.
Personally I'd suggest taking a look at the Service Bus again.
I am testing Microsoft's Azure cloud platform and am hosting two very low-requirement websites. One is a simple single form MVC website that simply accepts some input from the user, performs some calculations, and spits out an output. The second is similar, but it performs a simple query against an Azure SQL Server instance.
Both websites go down constantly. What appears to be happening is that if I don't hit the website for awhile (maybe an hour or so) the GET request simply fails. Nothing is ever returned from the server. If I wait a minute or two and try again, the website works perfectly.
Anyone know what's happening or how I can fix it? I obviously cannot host websites on this platform if the reliability is this low...
Windows Azure Websites used a concept of cold (inactive) and warm (active) sites that means as long as a website has active connection it will be warm or active and after some default time, when the website does not have any active connection it will go in cold or inactive site mode. Once a new connection is established to the same site the site will wake up from inactive (cold) to active (warm) mode and depend on what kind of content needs to be rendered on the website, it may take a few seconds to complete the startup process. The concept of warm and cold sites is described here.
Technically the first GET request will fail if it returns immediately for a cold website however this call does make the site active and next requests will result success.
There was a SO discussion in which the index page had to connect to DB to get the data and because the connection time to DB was longer which resulted the overall start time longer then expected. So there could be several reason by transition from cold to warm may be longer and you can contact Windows Azure Websites team to check why there is the case.
I have a web application that's consuming a WCF service. Both are slow on warmup after IIS reset or app pool recycle. So, as a possiible solution I installed Application Warm-Up for IIS 7.5 and set it up for both web site and wcf service.
My concern is, it doesn't seem to make any difference - first time I hit the site it still takes long time to bring it up. I checked event logs, there are no errors. So I'm wondering if anything special needs to be done for that module to work.
In IIS manager, when you go into the site, then into Application Warm-Up, the right-hand side has an "Actions" pane. I think you need the following two things:
Click Add Request and add at least one URL, e.g. /YourService.svc
Click Settings, and check "Start Application Pool 'your pool' when service started"
Do you have both of these? If you don't have the second setting checked, then I think the warmup won't happen until a user hits the site (which probably defeats the purpose of the warmup module in your case).
There is a new module from Microsoft that is part of IIS 8.0 that supercedes the previous warm-up module. This Application Initialization Module for IIS 7.5 is available a separate download.
The module will create a warm-up phase where you can specify a number of requests that must complete before the server starts accepting requests. Most importantly it will provide overlapping processes so that the user will not be served by the newly started process before it is ready.
I have answered a similar question with more details at How to warm up an ASP.NET MVC application on IIS 7.5?.
After you have fixed possible software/code optimizations allow me to suggest that each and evey code needs processing via hardware cpu. And our server skyrocketed in performance when we went to a multicore cpu and installed more GIGS of ram and connected UTP-6 cable insetad of standard UTP 5e cable onto the server... That doesnt fix your problem but if you are obsessed with speed as much as us, then you will be interested in the various dimensions that bottleneck speed.