Azure App Services
A feature of Azure App Service used to create and deploy scalable, mission-critical web apps.
4,560 questions
@Tomasz Kosek , Apologies for the delayed response from over the weekend.
Just to clarify and to isolate the issue, is this issue happening all of a sudden or is it happening from the beginning? How frequently does this issue occur?
How are you performing the deployment (method)? What is the application framework?
I understand after some tries, deployment is successful. Just to highlight, on Premium App Service Plan (ASP) tier, apps in the same ASP, share the same compute resources.
In a nutshell, the ASP is the scale unit of the App Service Apps. If the plan is configured to run 4 VM instances, then all apps in the plan run on all 4 instances.
--If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.
To narrow down the issue:
1.Review the logs, enable diagnostic logging and add instrumentation to your application, checkout the steps outlined in the doc
troubleshoot-diagnostic-logs
--Navigate through Kudu site on: https://<sitename>.scm.azurewebsites.net/api/logs/
2.You may leverage App Service diagnostics from Azure Portal> Navigate to your App Service app in the Azure Portal. (screenshot below)
-- In the left navigation, click on Diagnose and solve problems - Review - “Configuration and Management, “Availability and Performance”, and collect/review dump files.
!
at the other planns after dontet build, when dotnet build process took 1.5GB RAM, the build was killed. At the Standard S1 it didnt
@Tomasz Kosek , Thanks for the follow-up and update.
To provide better understand on this - Lower tiers (SKUs), like Shared or Basic are recommended for dev/test, that is non-production.
Production workloads come with the recommendation of the dedicated Standard pricing tier or above. While the price goes up for higher tiers, it also gives you more memory and storage and higher-performing hardware, giving you higher app density per compute instance. That translates to lower instance count for the same number of apps, and therefore lower cost
Since you pay for the computing resources your App Service plan allocates, you can potentially save money by putting multiple apps into one App Service plan.
You can continue to add apps to an existing plan as long as the plan has enough resources to handle the load.
You may wish to know:
What if my app needs more capabilities or features?
Plan and manage costs for Azure App Service
Example: (additional info)
If you scale an app in the Basic tier to two instances, you have 350 concurrent connections for each of the two instances. For Standard tier and above, there are no theoretical limits to web sockets, but other factors can limit the number of web sockets.
--maximum concurrent requests allowed (defined by maxConcurrentRequestsPerCpu) are: 7,500 per small VM, 15,000 per medium VM (7,500 x 2 cores), and 75,000 per large VM (18,750 x 4 cores).
Sign in to comment