I have a situation where my web garden is not using all the processes it can use. Is there some sort of client affinity with web garden, that each client will route to the same w3wp.exe worker?
Related
I'm looking to set up my alert rules and monitoring for an ASP.Net MVC application hosted as an Azure Web App, but I am a bit unsure of the nuances of monitoring in the cloud hosted environment.
To me the alerts associated with the WebSite (be it events or based on metrics) seem equivalent with what I'd like to have with an on-premise hosted site (ie. start/stop events, server errors, requests/Http 2..4 occurrence anomalies). The exercise is standard with monitoring any web server (from my understanding).
Having never administrated a server farm, I'm confused as to what metrics/events do administrators need to be alerted on with regards to the ServerFarm? The available metric list in Azure for alert rules is:
Data In, Data Out, CPU Percentage, Disk Queue Length, Http Queue Length, Memory Percentage. The available events are: delete, scale down, scale up. With regards to a server farm, when/what does ops need to be made aware of?
I think it's important to understand what a server farm is. For starters it is the same as the "App Service Plan" in the portal. What it is in practice is essentially a mapping between your worker servers and your websites within that App Service Plan, or server farm. This means that the metrics will be measured per worker server in your server farm.
If you only have one server and one site in your server farm, then these metrics would be equivalent to measuring that per site.
Thus if you were concerned about performance metrics such as high CPU use on your worker server machine you could configure an alert to notify you, or an autoscale rule to add more worker servers to serve your web site.
If Azure App Service plans are virtual machines dedicated to the Web, API, Logic, and Mobile apps defined within them, does that mean that a web app in an app service plan is an instance of a virtual web server in IIS on that virtual machine?
Assuming this is the case and that each virtual web site gets it's own application pool, is there an Azure scaling strategy or scenario where more than one worker process in that app pool will run, creating a web garden? My understanding of web app scale out is that it results in additional VMs being allocated and not additional worker processes.
The scaling strategy will depend upon the pricing tier you have opted for.
Basically each Service Plan will contain a collection of Web, API, Logic, Mobile apps. These will form a web garden within the Service Plan server you choose.
If you initially choose a single B1 Basic Service Plan, you will get a single virtual machine with all of your applications running on that. As the load on that server increases, you can scale it up to larger servers, but it will still be running on a single server.
If you then choose to create a second instance (and a 3rd, 4th, 5th...) that second server will be a replica of the first server, with the load being balanced between the two. (3,4...)
While I've not seen documentation for this, I would imagine that each Web, API, etc app is run under its own application pool / worker process, and scale out is simply duplicated instances.
I'm not sure what a Virtual Server is, but each app runs in its own dedicated application pool and w3wp.exe process. There is only a single w3wp.exe process per application pool, so no web gardens.
Is there a specific reason you think you need these to scale your apps? In most cases, using web gardens is the wrong way to scale, as adding more processes can cause unnecessary overhead (amongst other problems - you can find some useful resources on the web). You almost always want to prefer threads over processes for improving concurrency. If you're running out of physical resources (CPU, memory, etc), then the correct way to scale is to add additional VMs.
I have some doubts about Application pool
Multiple application in One Application pool running under the only worker process by default
Multiple application in One Application pool We can assign different worker processes for different applications.
Above is my Understanding about Application pool and worker process
I want to clarity in these concepts, If anybody have please explain me.
Thanks,
Dnyaneshwar
I think your understanding is almost correct.
When you create a new web site in IIS it creates an application pool
for you with the same name as the web site, so in fact the default is
every web app gets its own application pool.
You can set single application pool to host multiple IIS web sites. The
effect is that all the sites sharing the app pool are hosted in the
same exe. If you restart/recycle this app pool, it will restart all the web
sites it is being used in.
You can isolate different web sites by assigning different
application pools to each web app (as mentioned IIS does this by default)
One application pool has a single worker process (w3wp.exe) by
default but but you can increase this.
I am learning IIS. So when ever the application pool is created the id of that will be registered with HTTP.sys. So when the request come from client how it will found that request is belong to that particular id?
Then What is the use of Web Admin Services (WAS) ?
Obviously from IIS configuration (metabase or applicationHost.config) you can see a mapping for request path (such as /vdir1/file1.aspx) to an application pool. Such mappings are also loaded into http.sys, so that it can map incoming requests to the expected application pool.
WAS is a service that create/dispose w3wp.exe instances. It also reads IIS configuration to know how many application pools are there, and how to create worker processes based on the setting. BTW, its official name is Windows Process Activation Service.
I'm planning an application that has a mobile app as a front end (and perhaps a web front end also that performs a different purpose). Something like Runkeeper, or Runtastic, if you're familiar with those apps. The mobile device is the primary method of user interaction, and the web site has stats and dashboards that the users can view afterwards.
I would like the main application to reside in Windows Azure. I'm confused about how to architect the application though - should the business logic reside in a web role, or a worker role? If the main user interface is a mobile app, does it connect to the worker role to persist or retrieve data, or to a web role, or neither? I understand a typical scenario where a web role provides a user interface which can persist data directly to storage or pass data to queues or tables to be picked up by worker roles, but the presence of the mobile app throws me off.
Any help? Thanks!
Andy's answer is great, but let me add a different flavor. The only difference between a web role and a worker role is that the web role automatically has IIS turned on and configured. A good rule of thumb is that if you want IIS, use a web role. If you don't want IIS, use a worker role.
For hosting a server component for mobile apps to connect to, I think the simplest thing that would work would be a web role hosting an ASP.NET web application. Web applications can be used for services as well as web front end (HTML) web sites.
ASP.NET MVC and Web API make setting up web services really easy, and it's easy to work with non-HTML data formats, such as JSON or XML. Your mobile app could communicate with the web app using a REST JSON API, or you could use XML/SOAP if you wanted to, or whatever format you want. REST APIs with JSON as the transfer format is probably the most popular at the moment. One way to think about a web app is that it's just a way to send and recieve data from clients. If the client is a web browser, you can serve up your content as HTML pages, or if your client is a mobile app, you can serve up your data as JSON and let the client display it however it needs to. Basically, your web app can be both your web site (HTML), and your "API" for non-web-browser clients.
You can think of worker roles sort of like Windows Services. They are primarily used for doing back-end processing, and things like that. A worker role might provide some capability to host a public facing API, but you would have to manage connections, message pipelines, recycling, and all that yourself; whereas, a web role would have a web server (IIS) provided for you to manage connections, etc. If you are going to introduce things like message queues, it would make sense to have the public facing API be a web role, and the message processing component a worker role. The web app could receive the message from the client via a REST JSON API, and then pass the message off to a queue, where the worker role picks it up. Introducing queues and worker roles makes sense if you have heavy-duty server-side business logic that can be processed in the background without impacting the client.