Siva's IIS Blog start with basics! :-)

  • IIS Memory Management (Part 2)

    Hello everybody, I am back again to continue blogging on this topic; IIS Memory Management and this time, it is about In-Process & Out-Process Application Mode in IIS & 3-Tier Architecture in Web Application Services. Yes, it is indeed important to understand the varied application modes in IIS and how it is related in 3-Tier Web Application Architecture, before we get into the actual Memory Management scenarios. :-)

    As always, here we go with
    My Thoughts

    Application Mode

    IIS can be tuned in such-a-way that the
    application running on a webserver, could share the User Mode Memory space of the IIS service components. And, this configuration, which can be customized by an administrator on the IIS admin console, results as the Application Mode configured currently on that specific webserver; either In-Process or Out-Process. More specifically, you will find Application Mode configuration in the Home Directory tab of the website properties on the IIS Admin Console (inetmgr.exe)

    Did this explanation help you to understand the exact meaning of IIS Application Mode? Hmm.. I guess not! :-( ...what is lagging behind in this definition? I am pretty sure that the explanation is valid. As a beginner, I would immediately think of certain questions raised in my mind from that of the above detail as listed below:

    • What is an Application?
    • Is IIS not an Application?
    • When user is browsing a website, is it not the IIS as an application serving their requests?
    • what is User Mode Memory?
    • what is Kernel Mode Memory?
    • What is In-Process?
    • What is Out-Process?
    • If my server has 4 GB of RAM, the physical memory, it is the Operating System which deals on the processes and the memory allocation for each process. So, why would IIS come into picture on the memory utilization?
    • Where exactly does this "application mode" helps in IIS Memory Management?
    ... Okay.. enough for now!! :-) ...

    Let me now try to answer these thoughtful queries and help you understand the definition better.



    In a typical scenario, we have in most cases,
    three-tier architecture lay on the scope of any project design; the Presentation Layer which deals with the User Interface components, the Business Logic which deals with the Application & Webserver Components and the Data Layer which holds the actual data, typically on a database server.

    This application server and IIS service (usually hosted on the same server hardware, depending on the load / traffic analysis, we also tend to split the design by having a separate server for IIS and the application) takes the user input from a client browser, sends the query data to the application server, and the application then establishes connectivity to the customer database, which is a database server, fetches the records, again returns the output on the client browser.

    Still not clear about the above explanation…??? Okay, here we go with a bit in-depth…

    I believe it is for sure, going to be easy to understand this concept with a simple instance. Let us now think about a scenario as such, a list of Customer Contact Information, stored centrally in an organization and that can be retrieved from anywhere across the globe by the sales team. As soon an employee visits,
    website, we must think as what exactly happens and how the data is processed?

    Presentation Layer (User Services):

    Initially, the client browser locates (forget about DNS resolution for now, let us focus on IIS) the webserver which holds the ASPX pages. These client-side ASPX pages (cust-contact.aspx) will load client components and display a form to enter the criteria to search the entire customer database. User selects a Customer ID and clicks on Search. With this, we move on to the Business Logic (Application Layer) which is the Middle-Tier.

    Application Layer (Business Services):

    Based on the user input, the specific Customer ID, is the data which now Business Logic would be interested more about. To process the data to the data layer, the application server components might use a technology like, DAO / ADO / OLE DB, based on the product requirements and design, and establishes connectivity to the database server. Once the datasource is connected to the data access layer successfully, it then submits the query statements based on the programming modules from the application logic to customer database. The records are then retrieved from the customer database and again displayed on the client browser using HTTP port. Ofcourse, TCP ports might differ on the connectivity from Application Layer to the Data Layer. Whereas, between the client browser and the application web interface, most of the process takes place using HTTP modules, again, this process is totally based on the project requirements.

    Data Access Layer (Data Services):

    This initiates a process as soon the application logic starts the programming modules to establish connectivity with the customer database. It verifies the connection provider, the user / group authentication parameters, network path, database server instance and the database name. Once it confirms all these information, will then take the code submitted by the application layer which includes the user input (customer ID), and fetches the records from the customer database. Data is then returned to the Application Logic, which in-turn processes the data to the client browser.

    Well, this concept about 3-tier architecture is fine! But, where do we get IIS as a stand-point on the entirety? Precisely, what is the role of IIS here in the above scenario?

    Fine, let me now get into the specifics of IIS in the above scenario:

    The Windows Server OS with IIS component installed in it, which stores all the ASPX pages can be termed as a
    Webserver. IIS plays an important role as part of Business Logic (Application Layer) by providing a virtual path for users to browse the ASPX pages hosted on the Application Server. IIS is the webserver, which is part of the Application Layer, where-in we create a website (or, maybe the Default Web Site) in IIS admin console. Once created, we copy all the related ASPX pages (that includes the programming module of the application logic) to the path, that is shown in Home Directory tab of the website properties in IIS admin console (incase if it happens to be the Default Web Site, then the path by design in any IIS installation is C:\Inetpub\WWWRoot).

    Again, on the same Application Layer, the source code modules which processes and establishes connectivity with the data layer, processes the client requests to the database and fetches the records from the database to the client browser, can be termed as the
    Application hosted on the webserver (in some cases, you might even find certain application related executable images (.exe files) in task manager which are part of the actual Application Logic by itself.

    All these transaction happens on HTTP port, which means, the TCP Port 80 used by IIS to host a website by default. While browsing the website on a client browser, on the same client machine, when you execute netstat –a (or) netstat –n command using cmd.exe, you will find that your client IP (local IP) is using PORT 80 to connect to the remote website (foreign address). This TCP Port can be customized / changed based on the requirements from the Security Team in an organization, during the project design phase.

    Thus, IIS and the term Application differ in the Application Layer.

    Hope this abstract gives a practical note on IIS as a webserver! We started off with In-Process & Out-Process Application Modes and have come a long way till this level of understanding varied layers on a Web Services Architecture. It is always a suggestive approach to gain knowledge on the above concept, before we dig into the actuals of Application Modes, as such, these are unswervingly inter-related.

    Well, I suggest now to wait for my next blog to know more about
    the way IIS and Application Logic functions in the Application Services Layer (Middle-Tier) in a 3-Tier Architecture.

    Should you have a thought to share, pls click here. :-)



  • IIS Memory Management (Part 1)

    My thoughts:

    Here we go, with a simple terminology Memory Management. Is it something simple in reality? I guess not! (which is why, I have segregated this topic into multiple blog posts) Memory Management in any product has its own significant approach on handling process threads and client requests. Process Threads? Okay!! Let us not deviate to System Internals for now! :-) ...

    ...instead, allow me to rephrase it as IIS as a webserver has its own method of handling client requests! When we say Client Requests, it could mean a lot, such as, the load on the server, total number of sessions, total number of visits / pageviews, and so on! However, this area of Memory Management gets maximum importance as soon we think about dynamic websites.

    Now, what is a dynamic website? Well, answer is not just "Websites with dynamic web content!". :-) ... On a practical note, a dynamic website is one which has an effectual usage of the server memory space, while serving client requests to fetch or process a data, (which in most cases designed as a third normal form; resulting in primary key - foreign key database architecture) based on the criteria opted by the end-user. In such a situation, to trigger this kind of data manipulation / processing / transaction that occurs on the server memory space, we use programming languages like ASP.NET.

    This results in creating dynamic webpages where-in the webserver takes the complete load on an end-to-end scenario, which again means, memory utilization on the IIS processes, that is, inetinfo.exe / mtx.exe (IIS 4.0) / dllhost.exe (IIS 5.0) / w3wp.exe (IIS 6.0), as I have shared in my blog about IIS Version Comparison. This design on its entirety shall be termed as a dynamic website.

    Hope you find this blog a good start on IIS Memory Management!