I have a NodeJS server running on an Azure free website. The server has a websocket module installed. Each connected user will cache some data with an object so that anyone else who connects can retrieve cached data from this object. The problem I am experiencing is that the server doesn't seem to keep this object around for very long. I can access the data with in for some time, but if I try later in the day, it's just gone.
Is Azure shutting down the server because it is experiencing no activity, causing the object to be deallocated? Does NodeJS deallocate objects if they aren't used after some time?
Azure Websites, as Ben pointed out in his answer, will evict idle websites. This is especially true with free/shared tiers, since your website is sharing resources with several other tenants on the same VM instances. But even with basic and standard tiers, there may be a need to evict your website (especially since you can have many of your own websites running within a single hosting plan).
With basic/standard tier websites, you have the ability to enable Always On. You'll see this option under the Configure tab:
Once you enable this, your website should remain loaded.
Yep. If there aren't any requests to the app pool, Azure Websites stops your application. That means anything in memory is lost. You can set up a cron job or scheduled task to ping your web app to avoid the app pool timing out due to inactivity.
EDIT: Or, as David Makogon pointed out,
With basic/standard tier websites, you have the ability to enable Always On. You'll see this option under the Configure tab:
Related
We have a problem with an application hosted on Azure App Service Plan version P3V2. Depending on the traffic in our system, the App Service Plan is scaled up to 5 instances. During heavy traffic, one of the application instances stops responding to requests and after a few minutes it is restarted by the Auto Heal functions. We use Application Insights to monitor the application, unfortunately no logs are saved when there is a problem with the operation of this one instance, also in Event Log we do not see any logs that can help us.
Below I am sending a screen from last week showing all the situations when one of the instances stopped responding to requests.
We did not notice any jumps in the memory used in the application as well as the increased processor time.
I would be grateful for any suggestions or tips.
I want to use deployment slots for my Blazor server side application, but it stops working for the current users during the swap and they have to refresh the page.
I'm using an Azure SignalR Service for performance reasons, so it kinda makes sense, I imagine it like this:
Connections are held in memory and when I swap, obviously that is gone. At least without a SignalR Service. But shouldn't my SignalR Service keep SignalR connections (see red)? Did I set it up incorrectly?
I found others having similar problems (without using Blazor), but I'm not sure if these are viable with Blazor, especially because I just want to mitigate that 1-2 minute downtime for an update...
Automated reconnect
SignalR client disconnected on Azure slots swap
Storing connections in an external storage. But manually handling connections is absurd effort?
https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/mapping-users-to-connections
Update:
See: https://www.youtube.com/watch?v=Vvjdqq8MB44&t=12m10s
It seems there is "Web traffic" going directly to the Blazor app. My guess: After a swap the "Web traffic" still goes to the previous instance, while SignalR traffic goes to the newly swapped in instance. That sounds like a problem.
But once again, I have no clue what "Web traffic" actually is or if that is the problem and if Azure offers a way to solve the issue, so a definitive answer would still be appreciated.
I don't think you have it setup incorrectly. I looked into doing a similar thing and had the same results.
The azure signalr service is basically acting as a proxy, when you switch slot the azure signalr server is losing its connection to the blazor server hub which holds the current state.
I don't think there is anyway around it, when you want to update your blazor server site every connected client will lose its connection because it's not possible to move the client 'states' over to the new slot/site.
What would be nice is the ability for azure to switch the new slot in once all old connections have disconnected, but I don't think we'll ever get that as it's a very specific blazor server requirement.
What is happening behind the scenes when an App Service is restarted?
I'm trying to troubleshoot a slow restart for my app (ASP.Net and Sql published from Visual Studio) and I feel like understanding this would help me know what the issue is. My app starts within a few seconds on my dev machine but takes 90 seconds on Azure.
From my research, it sounds like a new service instance is provisioned, application files are copied from the shared storage to the instance and it is started. Is this correct? Is there a way to monitor the startup process to see what is slow?
Edit:
It's a tier S1 service plan. The app isn't slow, just the restart. I was hoping to understand the process so that I could understand whether the slow startup is due to my code or just the nature of the way the restart works. I've noticed that my app runs for about 10 seconds after the restart (refreshing the page), then I get a service unavailable for about 20 seconds, then the page is loading until for about 60 seconds.
It all depends which app service plan you are using, different plans have a different memory, network bandwidth, IO etc, App Service runs customer apps in a multi-tenant hosting environment. Apps deployed in the Free and Shared tiers run in worker processes on shared virtual machines, while apps deployed in the Standard and Premium tiers run on the virtual machine(s) dedicated specifically for the apps associated with a single customer.
Refer to this link for a guide on Troubleshooting slow WebApp in Azure.
Has you may know, Web sites hosted under Microsoft Azure Web Sites service are by default configure to timeout after idling 20 minutes (idleTimeout) and the application pool to restart every 29 hours (periodicRestart). This cause the web site to be slow for the first user accessing it.
I would like to know if the new "Always On" setting available on standard mode will prevent both situation from happening.
I found a few articles mentioning the feature, they are all very clear that the idle timeout will be avoided but none of them explicitly talks about the periodic restart:
One of the other useful Web Site features that we are introducing
today is a feature we call “Always On”. When Always On is enabled on
a site, Windows Azure will automatically ping your Web Site regularly
to ensure that the Web Site is always active and in a warm/running
state. This is useful to ensure that a site is always responsive (and
that the app domain or worker process has not paged out due to lack of
external HTTP requests).
http://weblogs.asp.net/scottgu/archive/2014/01/16/windows-azure-staging-publishing-support-for-web-sites-monitoring-improvements-hyper-v-recovery-manager-ga-and-pci-compliance.aspx
Also the Azure Documentation is not very explicit:
Always On - By default, web sites are unloaded if they have been idle
for some period of time. This lets the system conserve resources. You
can enable the Always On setting for a site in Standard mode if the
site needs to be loaded all the time. Because continuous web jobs may
not run reliably if Always On is disabled, you should enable Always On
when you have continuous web jobs running on the site.
http://www.windowsazure.com/en-us/documentation/articles/web-sites-configure/
Yes both of them will be prevented.
The default 29 hours periodicRestart was never on Azure Websites. That feature is an IIS feature that was enforced by WAS and was designed to run on a server level meaning restart all the worker processes on an IIS server. Both these things (WAS and IIS Server) don't apply to Azure Websites as WAS was the process management component of IIS and that was very specific to one box setup. Azure Websites uses a different process management component that doesn't have periodicRestart.
I am new to Microsoft windows azure cloud and want to run my game server using node.js in azure cloud. I read the windows azure Node.js Developer Center site and it seems my server can run in azure cloud multiple ways.
Which azure option is good for my TCP game server using node.js?
Three options:
Web Site
Cloud Service
Virtual Machine
Web Sites are essentially shared web hosting, which only supports HTTP, so not an option for you.
Cloud Services are probably what you want. This is the core PaaS offering on Windows Azure. It will let you run pretty much whatever you want, as long as it runs on Windows. It supports TCP endpoints. There's are pretty nice tools for Node.js. There are two flavors of running Node in a Cloud Service: a web role or a worker role. Web roles use IIS and run Node.js behind it. That won't work for your raw TCP connections, so you'll want to use a worker role. A worker role will simply launch your Node app and leave it running forever.
Virtual Machines would work fine too, but they don't provide much value compared to Cloud Services. In a cloud service, you can spin up new VMs on demand, a load balancer sits in front of your app distributing traffic, your app will get restarted if it ever crashes, you can have your VM automatically patched without downtime, etc. Unless you can't run in a cloud service for some reason, you rarely want to use a raw VM.
tl;dr You want a worker role in a cloud service. :-)
Windows Azure does have a toolkit for Social Games on Github, this might help you in you in your endeavours, not sure it supports Node.js mind you, there should be some takeaways to help you.
https://github.com/WindowsAzure-Toolkits/wa-toolkit-games
This blog post gives a good breakdown on where to run what and use cases for each.
http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to-use-which.aspx
It really depends on your application, what backend does it have, number of users, performance, latency etc...
A word of warning though, running Node.js on Windows is mostly fine but there are several libraries that will not work. Don't know if it's a hard requirement that you use Azure but there are other Node hosting solutions out there.
Nodejitsu
Nodester
Those are only two, there are more out there.
Disclaimer: I'm building a Node.js hosting solution, modulus.io.