See Also: System Architecture Replication Web Site Optimization Techniques

---

A web farm is a group of two or more servers used to host the same site.  Web farms increase the capacity of a web site, and improve availability by providing fail-over.  Web farms are universally used for high-traffic and mission critical web sites.

APGen has been used successfully in large web farms.  In fact, the cost savings from using APGen increase significantly as the size of a web site grows.  APGen optimization typically makes web sites 3 to 10 times more efficient - using the lowest multiple of 3x, a 5 server web-farm optimized with APGen can handle the user load of a 15 server, unoptimized web farm.  The savings in hardware, software, hosting, electricity, and IT from using 10 fewer servers is significant.

A well-designed system will scale from a single server (where the web server, APGen, and perhaps the database server all reside on a single server) to a web farm (where multiple web servers work in parallel, and APGen and the database each run on their own servers) without changing the application.  There is extra work in designing a system that will scale out - consider whether this is likely to be necessary before designing your system.

Design

A web farm architecture is used for two reasons: Increased capacity; and increased availability. 

If availability is critical, all major functions of the site should have backups.  This includes backup web servers, backup database servers, backup domain servers, backup firewalls, and backup APGen servers.  These backups can either be offline until a failure occurs; or they can be online all the time, acting as a duplicate server.

If capacity is the main reason for using a web farm, a multiple web server and single domain, database, and APGen server configuration may be sufficient.  The most common point of failure is web servers, so this design provides a good compromise between high availability and reasonable cost.

In a web farm, all web servers should be homogenous - the hardware does not have to be the same, but it should be similar.  Each web server should have the same software, configuration, and web site files.  A replication system should be used to ensure that all web servers have the same web site files, even as those files change.

APGen Servers

For web farm systems, APGen integration can be architected two ways:

• Run APGen on all web servers.  This can be used when APG scripts are synchronously executed by ASP pages.  Output is written to a replicated share, preferably a DFS share. 
• Run APGen on a separate APGen Server (a backup APGen Server may also be used for fail-over).  In this architecture, APGen is used in a distributed system, where page updates are signalled from any of the web servers, database servers, or application servers.  Output is replicated to all web servers.

For ISPs and companies hosting multiple web sites per web server, we recommend running APGen on each web server, so each hosted web application can use APGen independently.  We also recommend running APGen on the web server for single server sites that are not foreseen to need a web farm.  For large web sites using a web farm, we generally recommend using a distributed APGen Server.

ASPCache

Whether APGen is run on all web servers, or on a separate APGen Server, the ASPCache component should be run on every web server in the farm.  Though content generation may be moved to a separate server, data and page fragment caching is performed on each web server.

Distributed APGen Server Architecture

The system architecture when using a separate APGen Server will vary depending on the needs of your application.  The system should execute the APG scripts as needed - this is usually done with DCOM or another communication system.

Designs options include:

• Scheduled page updates.  The scheduler is used to run scripts that query for changed data and generate changed pages every so often.
• MSMQ based page updates.  The APGen server hosts a queue that receives content update messages.  These content update messages can be sent from ASP pages, SQL triggers, or other applications.  The MSMQ example (see the Examples topic) shows how to do this.
• DCOM updates.  A wrapper component on the APGen server is installed in a MTS or COM+ Server application.  Proxies to this component are exported to every computer on the web farm, so that DCOM calls can be made from any of the web servers or from the database server.  This design is good if synchronous updates are required.  This design may be used with an MSMQ-based design to provide both synchronous and asynchronous updates.
• Queued component updates.  A wrapper component on the APGen server is installed in a COM+ Server application as a queued component.  Proxies to this component are exported to the other computers on the web farm, so that calls can be made from any of the web servers or from the database server.  This architecture is comparable to the MSMQ based page updates, in that both systems are asynchronous and leverage MSMQ.

When designing a system that may have large spikes in content update workload, or that must be fail-proof, the systems using MSMQ are ideal.  Under most conditions, queued content updates are executed immediately - there is virtually no delay between issuing the content update message and generating the content.  However, when the system comes under heavy load, or a failure occurs, MSMQ handles the situation gracefully.  Under heavy load, content generation is delayed but ensured.  When a failure occurs, messages accumulate in the queues until they can be handled, so no content update requests are lost.

APG Script Output

When using a web farm, the same content and web files must be maintained on all web servers.  This means the output directory must be replicated between all web servers.  One easy way to do this is to write to a DFS (Windows 2000 Distributed File System) share that has automatic replication enabled.  For more information on DFS and other replication systems, see the Replication topic.

To write to a DFS share, set the APGen.OutputDir property or the Output.Dir property as follows:

oAPGen.OutputDir = "\\domain\dfs_share\subdir\" ' DFS share

The Logon object can be used to connect to the share using a specific user account:

' Create an APGen object
Dim oAPGen
Set oAPGen = CreateObject("APGen")

' Set the logon properties
oAPGen.Logon.User = "APGen_User"
oAPGen.Logon.Password = "pass"
oAPGen.Logon.Domain = "domain"

' Set the output directory
oAPGen.OutputDir = "\\domain\dfs_share\subdir\" ' DFS share

' Execute some APG scripts...
oAPGen.Run "default.apg"

---