What would be the best way to monitor when our Azure web app is being unloaded when no requests have been made to the web app for a certain amount of time?
Enabling Logstream for the web server doesn't seem to reveal anything of use..
Any hints much appreciated!
You can use Azure Application Insights to create a web test that will alert you when the site is not available anymore. It will ping your site from the data centers you select and perform some action you select (mail, webhook, etc).
However, if you want your web app to stay online, you could upgrade its plan to be at least basic, and under settings enable always on.
In addition to the kim’s response:
If you are running your web app in the Standard pricing tier, Web Apps lets you monitor two endpoints from three geographic locations.
Endpoint monitoring configures web tests from geo-distributed locations that test response time and uptime of web URLs. The test performs an HTTP GET operation on the web URL to determine the response time and uptime from each location. Each configured location runs a test every five minutes.
Uptime is monitored using HTTP response codes, and response time is measured in milliseconds. A monitoring test fails if the HTTP response code is greater than or equal to 400 or if the response takes more than 30 seconds. An endpoint is considered available if its monitoring tests succeed from all the specified locations.
Web Apps also provides you with the ability to troubleshoot issues related to your web app by looking at HTTP logs, event logs, process dumps, and more. You can access all this information using our Support portal at http://.scm.azurewebsites.net/Support
The Azure App Service support portal provides you with three separate tabs to support the three steps of a common troubleshooting scenario:
-Observe current behavior
-Analyze by collecting diagnostics information and running the built-in analyzers
-Mitigate
If the issue is happening right now, click Analyze > Diagnostics > Diagnose Now to create a diagnostic session for you, which collects HTTP logs, event viewer logs, memory dumps, PHP error logs, and PHP process report.
Once the data is collected, the support portal runs an analysis on the data and provides you with an HTML report.
In case you want to download the data, by default, it would be stored in the D:\home\data\DaaS folder.
Hope this helps.
Related
I have deployed two Azure web apps containing web jobs that perform sending of emails. It's the same code deployed with minor web.config changes and pointing to different dbs with the same structure. They use the same SMTP channel (smtp.office365.com, port 587), and server A is on a higher spec and takes 6 seconds to send an email, and server B is on a lower spec and sends an email in under a second. Both are located in South Africa North. The performance measurement is strictly around the sending of the email, so it can't be a db issue.
Both servers are operating well and I can't see any obvious performance issues. The times taken to send emails are consistently around the same speed throughout the day.
Where should I look to resolve this difference?
You can follow troubleshooting steps to understand the web apps slow performance:
Yes, it may not be a db issue.
Recheck those minor web.config changes that is pointed to different dbs.
Troubleshoot for less performance on the web apps.
Like some of the steps are Service Health checks, Monitor Azure WebJobs, Metrics.
Any program code or database queries are in-efficient.
You can enable application diagnostics and use the Application Insights Profiler.
Use AutoHeal, as it recycles the WP (worker process) on configuration modifications and to execute the request on the given time. And you can restart the web app from portal, if you need this by automatically then you can make use of this AutoHeal.
To automate this on your web app you need to add triggers in the web.config file in the root.
Hope there is no link between sending emails with the help of database, means you are not getting the data from db then sending the emails.
I know this has been asked before, but I tried all known solutions and still no luck. I have a request that returns roughly 26MB of JSON. It is returning a 502 on my azure web app. I have set maxRequestLength and maxAllowedContentLength to their max allowed values as detailed here.
How to set the maxAllowedContentLength to 500MB while running on IIS7?
I have also set the applicationHost.xdt on the site folder of my webapp and verified it is applied as detailed here.
ApplicationHost.xdt in Azure Web Apps
None the less, my request timeout at exactly 4 minutes every time. I can run the same request against my localhost running on iisexpress pointed to the Azure SQL database and it returns the data, so I know this is something azure webapp speciic.
I have enabled all types of logging in "App Service Logs" section of my webapp. I see other failed request traces for 401 when session expires, but this request doesn't log a failed request trace, or an application error. In live log stream it shows the request as a 200 response in the web server logs.
Any other ideas?
Thanks for a detailed question and sharing the solutions that you have already tried. I'm unsure if "Always ON" feature is turned on on your WebApp. Such time-out error may occur due this,so kindly enable it and let us know for further investigation.
Additional information, Azure Load Balancer has a default idle timeout setting of approximately four minutes (230 sec); this is a general idle request timeout that will cause clients to get disconnected after 230 seconds. However, the command will still continue running server-side after that. For a typical scenario, this is generally a reasonable response time limit for a web request. In such scenarios, you could look at async methods to run additional reports. WebJobs or Azure Functions is another option.
If ‘Always On’ config is not turned On, please do turn it on. The AlwaysOn would help keep the app loaded even when there's no traffic, it will send a request to the ROOT of your application. Whatever file is delivered when a request is made to / is the one which will be warmed up and this feature comes with the App Service Plan is not charged separately
1) From the Azure Portal, go to your WebApp.
2) Select Settings> Configuration > General settings.
3) For Always On, select On.
I have an app service plan which is hosting 2 Web APIs, the issue I am facing is that I am unable to view details such as: CPU Usage, Memory Percentage, Requests, Average Response time etc.
These can be found under the Overview tab for both App Service and App Service Plan but no data is being recorded, even if I retrieve data for the whole week rather than the last hour only.
I have also confirmed that I am hitting the correct App hosted on the correct Plan. Have I missed anything? Do I need to enable something?
I have also generated around 20k requests in the last few hours so I expect something to show up.
How does one diagnose performance (response time) bottlenecks in Azure?
I've got a .NET Core website on Azure that consists of a web app service and one SQL database.
I've set up load test and deployed it via the cloud to hit the website. Configuration properties for the load test agents are
4 cores
start at 10 simultaneous users, + 10 every 20 seconds, up to 150 users
5 second think time between requests
Web app resource allocation is as follows
2 instances of
4 Core, 7GB RAM (S3 Standard)
This image shows the hardware utilization during the load test (2 tests shown, around 1pm and 1:30pm)
Seems reasonable, except my response times are, in my opinion, too slow, considering the hardware isn't stressed at all. For instance, at 10 users, my response time starts at 20ms, but at 150 users (at the end of the test), I'm seeing 5 second response times.
For the last portion of the test, My requests per second was at about 50.
Database performance, at 100DTUs, doesn't seem to be a factor:
What else can I do to diagnose slow response times? If the web server hardware isn't pegged, and the database isn't even sneezing, what other knobs can I turn on Azure?
The long response time bottleneck can be caused by various reasons, for example, bandwidth restrictions, source limited, bad application design, dependency of tightly coupled component etc.More information about how to troubleshoot slow web app performance issues , please refer to the document. There are some snipped from the document.
Enable diagnostics logging for your web app.
WebApp provides diagnostic functionality for logging information from both the web server and the web application.
We can enable Detailed Error Logging, Failed Request Tracing, Web Server Logging for web server diagnostic
Use Kudu Debug console (https://. scm.azurewebsites.net/)
Kudu provides environment settings for your application, log stream, diagnostic dump
We also can use Azure Application Insights to monitor the usage and performance of our app, then we can get more detail info about request, more detail exception info, response time and so on.
If we get more detail info about application exception, request failed, server logs and application log, it will be more helpful for us to diagnose.
There are also some related articles about how to diagnostic Web App and how to use Application insights:
Enable diagnostics logging for web apps in Azure App Service
Monitor performance in web applications
Diagnose exceptions in your web apps with Application Insights
Using Search in Application Insights
Try using new relic extensions
It provides great insight to response time and lot more with the free account
You can also enable application insights on the web app. It will provide you with details on response time and other details
I'm trying to figure out a solution for recurring data aggregation of several thousand remote XML and JSON data files, by using Azure queues and WebJobs to fetch the data.
Basically, an input endpoint URL of some sort would be called (with a data URL as parameter) on an Azure website/app. It should trigger a WebJobs background job (or can it continuously running and checking the queue periodically for new work), fetch the data URL and then callback an external endpoint URL on completion.
Now the main concern is the volume and its performance/scaling/pricing overhead. There will be around 10,000 URLs to be fetched every 10-60 minutes (most URLs will be fetched once every 60 minutes). With regards to this scenario of recurring high-volume background jobs, I have a couple of questions:
Is Azure WebJobs (or Workers?) the right option for background processing at this volume, and be able to scale accordingly?
For this sort of volume, which Azure website tier will be most suitable (comparison at http://azure.microsoft.com/en-us/pricing/details/app-service/)? Or would only a Cloud or VM(s) work at this scale?
Any suggestions or tips are appreciated.
Yes, Azure WebJobs is an ideal solution to this. Azure WebJobs will scale with your Web App (formerly Websites). So, if you increase your web app instances, you will also increase your web job instances. There are ways to prevent this but that's the default behavior. You could also setup autoscale to automatically scale your web app based on CPU or other performance rules you specify.
It is also possible to scale your web job independently of your web front end (WFE) by deploying the web job to a web app separate from the web app where your WFE is deployed. This has the benefit of not taking up machine resources (CPU, RAM) that your WFE is using while giving you flexibility to scale your web job instances to the appropriate level. Not saying this is what you should do. You will have to do some load testing to determine if this strategy is right (or necessary) for your situation.
You should consider at least the Basic tier for your web app. That would allow you to scale out to 3 instances if you needed to and also removes the CPU and Network I/O limits that the Free and Shared plans have.
As for the queue, I would definitely suggest using the WebJobs SDK and let the JobHost (from the SDK) invoke your web job function for you instead of polling the queue. This is a really slick solution and frees you from having to write the infrastructure code to retrieve messages from the queue, manage message visibility, delete the message, etc. For a working example of this and a quick start on building your web job like this, take a look at the sample code the Azure WebJobs SDK Queues template punches out for you.