I am experimenting with Application Insights (v0.14.0) and an ASP.NET application that I maintain, and I am finding its data collecting to be quite erratic. For a while, I was only getting client-side data being published (e.g. Browser Page Load Time) but none of the server metrics. I checked that the ApplicationInsights.config file was in both the web root folder and in the bin folder as per Application Insights not showing data in Azure Preview Portal, and that the correct instrumentation key was being used. We are not currently running the AI agent application.
Last night we deployed a new version of our application, without changing the AI configuration, and suddenly the server metrics started coming in. Hurrah! Unfortunately, 45 minutes later we deployed a single assembly hotfix to the application, and after the app pools had been recycled, the server metrics stopped, and this time the client metrics stopped as well.
Opening up the web application in my browser, I can see the AI.js script being loaded, and looking at the outbound network calls, I can see the telemetry being successfully submitted to AI:
Remote Address:23.101.207.84:443
Request URL:https://dc.services.visualstudio.com/v2/track
Request Method:POST
Status Code:200 OK
Any ideas what's going on?!
Unfortunately yesterday we had issue in the pipeline, that was causing latency of upto 4 hours. You can always get information on the service at http://aka.ms/aistatus. We are still working through some of the issues, but they are mostly resolved.
Related
The website hosted in IIS 10, website developed using Classic ASP and .Net Com DLL.
.Net dll registered by following comment
RegAsm.exe XXXX.dll /codebase
Website work fine when single user access the website but when multiple user give the concurrent requests then site starts loading.... and no response received, it's loading until we close the browser window.
When the website has long loading.... in one browser(chrome), if I tried same website in another browser(firefox) it's working normally but in chrome it's still loading...
I have verified log details there is No updates in iis log files, but we have logs for other requests until loading issues came
There is no updates in httperr file.
If we restart the IIS it took some time to restart and got the following WAS warning in system event log,
A worker process '####' serving application pool 'XXXXXXXX' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
My IIS nested application hangs when I browse from IIS -- browser's busy spinner just spins forever.
I added a 2nd VS ASP.NET web app project to my primary web site, as a IIS 'nested' application.
The 2nd web app project debugs from VS OK and opens browser to it.
Is it possible to break in with debugger to see if code is in a loop or something?
BACKGROUND:
IIS 6.5 on my Windows Server 2012 R2 Azure VM
VS is 15.3.4
IIS > Sites > my primary web site > TEST (this Application added to primary) > Advanced Settings:
App Pool = DefaultAppPool
Physical Path = path to TEST's VS project
Virtual Path = /TEST
IIS 6.5...
Test Settings...
If you aren’t sure what issue is causing your website to spin forever, look at the live requests within IIS. From the IIS Management Console select Worker Processes.
Right click on your running application pool and select “View Current Requests”.
This will bring up a list of the currently running ASP.NET web requests as shown below.
I would suggest looking at the “Time Elapsed” to see if you have a lot of requests that are taking a very long time. You should also see if they are all stuck in the same module. This could be a clue that the issue is all related to ASP.NET Sessions or some other step within the ASP.NET request life cycle. You may also be able to identify a specific URL that is causing the problem.
Also in addition to that , I would highly suggest using a logging framework like NLog, log4net or Serilog. You can then send them to a log management service to make it easier to search them across multiple servers. Application logs are good way to trace your application trace across server.
If your web request is returning a 500 Internal Server Error, you need to check your server-side logs for exceptions. As mentioned above about application logs in general, it is important to have good exception handling in place and properly logging all of your errors.
Also you could use some open source diagnostic tool like Glimpse to trace. Glimpse is a thriving and growing family of open source NuGet packages that provides detailed performance, debugging and diagnostic information for ASP.NET apps. It's trivial to install, lightweight, ultra-fast, and displays key performance metrics at the bottom of every page. It allows you to drill down into your app when you need to find out what's going on at the server. Glimpse provides so much valuable information we recommend you use it throughout your development cycle, including your Azure test environment. While Fiddler and the F-12 development tools provide a client side view, Glimpse provides a detailed view from the server. You can try using that too.
Hope it helps.
I had Application Insights running smoothly on an Azure Web App via the AI SDK, reporting to an AI instance hosted in Azure.
The only niggle was it didn't show detailed dependancy diagnostics, according to this page this was because I was using the SDK only, I needed to "Instrument your web app on the server", which looking at the docs can't be done if you already have an instance of AI running....helpful!
Reluctantly I deleted the AI instance, stripped the SDK from my code so I was starting fresh, and followed the steps, however as soon as I finished the process in the previous link my website broke and now responds to every single request (MVC5 and Web API) with an empty 404 request
The AI status page is showing green ticks for everything, and I can't discern anything from diagnostic log dump from KUDO or manage to remotely debug the site.
Deleting the AI extension under Web App -> Extensions in the Azure portal and then restarting the web app fixes the problem.
I've run out of ideas on how to fix this, is there anything else I can do to get to the bottom of the problem?
To fix this problem, delete the following 2 files from your web app's (or slot's) filesystem:
D:\home\siteextensions\Microsoft.ApplicationInsights.AzureWebSites\Instrumentation32\ProductionBreakpoints_x86.config
D:\home\siteextensions\Microsoft.ApplicationInsights.AzureWebSites\Instrumentation64\ProductionBreakpoints_x64.config
You can do this easily through Kudu.
Edit: Apparently this is/was an issue with the ProductionBreakpoints interacting with precompiled views. Microsoft has informed me a fix should be out within the next couple days. The version of Application Insights extension I have now that is still broken is 2.4.6 - I will post the "fixed" version when I can confirm it.
Edit 2: Confirmed this is fixed in 2.4.7 which is out now.
We are just starting to deploy our hosted web application in an Azure environment. We have the database running as an Azure SQL Database and the web application running as an Azure App Service Web App (including a continuous WebJob). We are having some significant performance issues with the Web App and I am hoping to get some advice on how to resolve these performance issues.
Here are some key points:
The Web App is deployed as a compiled web application (binaries, markup, *.resx files), not source code
The Web App is deployed via FTP
The Web App has "Always On" turned On
The App Service is running in the South Central US Azure datacenter
The Azure SQL Database is also running in the South Central US Azure datacenter (so database latency should be minimal)
We have an exact replica of the Web App (same binaries, etc.) running on a non-Azure server in a datacenter in Los Angeles (if database latency were the issue, this site would have worse database latency)
Both instances of the Web App (Azure and non-Azure) are connecting to the very same Azure SQL Database (running in the South Central US Azure datacenter)
I have been testing from a workstation in Utah – not particularly close to either web server
On any “cold” request (site has been idle for a period of time), the Azure site seems to be significantly slower. Pages that load quickly from the non-Azure server take a long time (e.g. 20 seconds or longer) from the Azure server. The content is the same, and both apps are accessing the same database – so I don’t believe it is a database issue. I have narrowed it down to two .NET functions that seem to be the problem:
System.Web.UI.TemplateControl.GetLocalResourceObject(string)
System.Web.UI.TemplateControl.LoadControl(string)
The application includes *.resx files for a few different languages. When a request comes in, it uses the culture in the request header to load the correct resources. The GetLocalResourceObject function seems to be compiling the *.resx files on the fly, which seems to take several seconds on the Azure server. I may need to try something like this to prevent Azure from compiling *.resx files on the fly.
Some of our pages load controls dynamically, hence the call to the LoadControl method. These controls are deployed as *.ascx markup, but the code-behind is already compiled into a *.dll in the .\bin folder. Even though the controls are already compiled, it appears that the LoadControl function is trying to compile each control, which takes several seconds on the Azure server.
A “warm” page access seems to go more quickly on the Azure server (almost as quickly as the non-Azure server), probably because the resources and controls are already compiled and still in memory. I have yet to be able to determine at what point the resources/controls have to be recompiled.
I am trying to figure out the best way to make the site respond well, even on a “cold” request. I have tried running aspnet_compiler.exe on the Azure App Service server (via Kudu CMD). That seems to work sometimes, but it has not been very reliable (sometimes it doesn’t seem to work, or the process doesn’t seem to complete). It also seems that, even after compiling the site, the problem returns after a period of idleness.
Our primary objective is to get the Azure App Service Web App to perform acceptably. It seems that the only way to do that is to force the Web App to precompile the resources and user controls so they are not compiled on demand. I have yet to find a reliable way to accomplish this objective. Any help or insight would be appreciated.
I am hosting a website on Azure Websites, and starting around 10AM CST today, I have been unable to deploy for the following reason
Web deployment task failed. (Could not connect to the remote computer ("waws-prod-chX-XXX.publish.azurewebsites.windows.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.)
On top of that the site keeps giving a 502 gateway error (after 5 minutes), BUT the Azure dashboard shows everything is up: http://www.windowsazure.com/en-us/support/service-dashboard/
I use the Standard Mode on a Small VM which I share between 3 other sites, the other sites are all fine, and I can publish to them, just not this one. They all have the same web deployment server.
In my case I experienced the same error, and did not see anything wrong in the console. Then right as the hour turned over, I was able to do it again.
There must be some setting that only allows X number of WebDeploy resources to be used per hour.