Scaling IntraWeb Applications

Last Updated: 9/22/2008

Sections above here:
Home » Deployment » Performance Considerations

Sections below here:

Topics in this section:
Performance Considerations
Scaling IntraWeb Applications

What if my application grows too big for one server to handle? Can IntraWeb scale? Sure it can. IntraWeb can be scaled using a variety of methods. First also consider that in many applications you can handle more with less CPU because App mode is stateful. Without state, applications often spend a lot of CPU streaming state to a DB, reconstructing state, or needlessly rerunning queries against a database. That being said, there are still times you need to scale

Profile your application first

When you run into the situation that your application runs "too slow", then first, before thinking of scaling, try to profile your application and find where the bottlenecks are. If the bottleneck is the database (i.e. queries have long response times), then it makes no sense to add an other IW application server of course. Also make sure that you have read through the general performance evaluation article.

When you know your bottlenecks, then you can start evaluating a scaling solution. IntraWeb can be scaled using a variety of methods:

Add Another Tier

Use MTS, COM, SOAP, ASTA, Midas, whatever and split that piece into multiple machines. This will take processing out of the IntraWeb application and allow it to be distributed.

Beef Up You Database Server

Add more CPU power or memory to the database server. In many systems, the database is the bottleneck, and the web application spends the majority of its time waiting on the database.

Add More Memory to Application Server

Check your memory usage and make sure that your application server has the appropriate amount of memory. Virtual memory will be used if not enough physical memory is available, but this will slow down the response time and consume CPU cycles. Eliminating the use of virtual memory will increase efficiency and capacity.

Use a Multi-Processor Server

IntraWeb servers are fully threaded. Thus, IntraWeb servers will take advantage of multiple processors if present.

Distributed IntraWeb Applications

If you have reached a level that requires you to scale the actual IntraWeb application, this can be accomplished as well.

Load Balancers

A very effective method to distribute one IW application to multiple machines/servers is to use a Load Balancer. A Load Balancer listens on one address (e.g. http://www.yourappdomain.com) and dispatches all incoming requests. A typical example is that requests to http://www.yourappdomain.com/ApplicationOne would be redirected to cluster of lets say 3 servers (which do not need to have a public IP). The Load Balancer keeps track of the originating IP's and remembers (in a stateful manner) what IP has a session on what cluster-server. The response of the cluster servers is then dispatched back to the originating IP/web browser.

An excellent load balancing product that is proven to work with IntraWeb applications is OctaGate Switch : http://www.octagate.com/

Distributing Using Standard Methods

What will be presented here is not the only way that an IntraWeb application can be distributed, but it is the most common. It is very simple, and effective. This method can also be used in conjunction with the previously described methods.

Step 1 – Install Multiple Application Servers

Each server will need it's own IP address. For this example, we will simply refer to them as .1, .2 and .3.

Step 2 – Create a New DNS Record

Create a new DNS entry to identify the application. For this example, we will use iwapp.atozedsoftware.com.

Step 3 – Add Multiple IPs for the DNS Record

DNS allows multiple IPs to be assigned to a given record. In our example, we would assign .1, .2, .3 to iwapp.atozedsoftware.com. When multiple IPs are assigned to a single record, the DNS server will perform rotating DNS, sometimes also referred to as round robin. This means that the first request for iwapp.atozedsoftware.com will return .1, the second will return .2, the third will return .3, the fourth will return .1, and so on.

This will distribute the load across the servers. This method does not perform true load balancing, as it does not measure the load, it just distributes it. In most applications, the law of averages applies and it is quite effective. If your application is such that it creates large imbalances, you will need to use a load balancing DNS server instead.

Step 4 – Create a Redirect Entry

On each application server create a redirect entry using the primary web server's configuration, or a page that performs a redirect to that servers actual IP. When the page or virtual entry is requested, the browser will not know that it has been redirected to an IP by the DNS server, as this is part of its normal operation. However, we must make sure that subsequent requests are routed to the same application server, as IntraWeb is stateful. Note that this only applies to Application Mode, and not Page mode. This step can be skipped for Page Mode.

The virtual entry or web page merely redirects the web browser to a URL containing its individual IP instead of iwapp.atozedsoftware.com. For example if our URL is http://iwapp.atozedsoftware.com, this entry might redirect the browser to . This URL demonstrates a stand alone IntraWeb application, but it can be adjusted to redirect to a static page, an ISAPI version, or a DSO version. The important thing is that the browser is redirected to the physical application server so each subsequent request will return to that server.