Using the Web Application Administrator

The Web Application Administrator provides the following capabilities for managing your Web and Web Service applications:

  • Add, disable or delete applications

  • Start, stop or restart applications

  • Start, stop or restart the Web Application Server

  • Monitor current activity

  • Examine and clear event logs

  • Examine and edit application properties

  • Terminate sessions

  • Launch the Windows Event Viewer


Web Application Properties

Each Web or Web Service application may have the following properties set independently:

  • General

  • Process Pooling

  • Load Balancing

Related Topics

Load Balancing Server Properties


General Properties

Program File

Filename

The program filename for this web application.

Parameters

Additional command line parameters for this program

Logfile

Filename

The name and location of the private log file for this web application

Log all access

Selects whether all access to the web application should be logged, i.e. Session Started/Session Closed events. This setting does not affect error logs. All application errors are always logged.

Maximum log entries

The maximum number of log entries in the application log file. When this number is exceeded, the oldest log entries are replaced.

Disable Web Application

You can temporarily disable access to a specific web application. This is useful if you need to update certain components of your web application but you do not want to interfere with or stop other web applications from running on your system.


Load Balancing Options

Load Balancing Properties

The radio group determines how the application should be configured on this machine.

  • Select the first option to configure this machine as a slave node for the purposes of this Web Application. It will be controlled by another machine designated as the master node.

  • Select the second option to configure this machine to run the Web Application locally, with no other machines involved. It is therefore not configured for load balancing.

  • Select the third option to configure this machine as a master node for running the Web Application. It will then be load balanced over the slave nodes entered. Use the Add, Remove and Edit buttons to enter the IP addresses of the machines which will participate. For each machine which will participate, enter the port and weighting to be applied.

Related Topics

Load Balancing Web Application Server


Process Pooling Options

Process Pooling Properties

Process Pooling in Enterprise Configurations

Process Pooling is disabled if the application is configured to run as a slave node. In that case, process pooling can be configured from the master node. If this is a master node, you may check the first box for it to use Process Pooling. If not, the other options will be shadowed and unavailable.

Minimum and Maximum Pool

The minimum pool is the minimum number of the application's processes to be kept in the pool at all times. The maximum pool is the maximum number of the application's processes which will be allowed to run at the same time. If the server load exceeds this setting, new requests are queued and served in FIFO (First In, First Out) order.

Automatically Reload

Check one of the Automatically Reload options if you want the application to automatically reload after the specified number of hours or daily, at the specified time. This setting configures whether the application's process pool should be automatically flushed and, if so, how often. You can specify that Web Application processes are closed and reopened after a specified number of hours. This ensures that the oldest processes get "refreshed" from time to time. Ideally, you should never have to use this setting (because a "properly" written program runs forever) but, since "properly" written programs hardly ever exist, you may wish to use it. The default option is to not automatically reload the process pool.


Server Properties

General Options

Load Balancing Options


General Web Application Server Options

General Server Options

Click the View menu and select Options.

Administrator

The Administrator option regulates the frequency in which the Administrator panels will be refreshed.

Timeout Values

The Timeout values affect internal behavior of Web Application Server. These are normally left untouched, unless your web applications have some specific and lengthy operations. Whenever a timeout occurs, Web Application Server creates an entry in the NT Event Log. If you experience timeouts, you can change these values.

Performance

The Max concurrent sessions option holds the maximum number of sessions that are allowed to run simultaneously. If set to zero, no limit applies. This setting is a security measure, securing your server from session bombing (i.e., protecting your server from not starting more sessions than memory and CPU can handle).

Normally, this value should be set to the highest number of sessions your server can handle without running out of memory. Alternatively, if you do not have a dedicated server, you might want to set this to a lower value, thereby effectively saving memory and CPU resources for use by other applications and services on your server.


Load Balancing Web Application Server Options

Load Balancing Server Options

Load Balancing Slave Mode

Check the first box if this machine may participate in the Server's load balancing activities. If so, enter the TCP/IP port number that is to be used.

Restricting Load Balancing Requests

Select the first radio button if you want this Slave machine to accept requests from any Server machine. Select the second radio button if you want this Slave machine to only accept requests from one or more Server machines, specifying their IP addresses. Use the Add, Remove and Edit buttons to maintain the list of IP addresses.


Add a New Web Application

To add a new Web Application to your server, do the following:

  1. Using the Web Application Server Administrator, select New Web Application from the File menu. The Configure New Application wizard will start.

  2. Select the type of the application you are adding: local application; load balancing master node; load balancing slave node.

  3. Proceed with the wizard, filling out the forms and selecting the adequate options -- the wizard will require different pieces of information, depending on the type of configuration selected.

Note: When you are presented with the Log All Access to the Application checkbox, check that option if you want to log Session Started and Session Closed events. Uncheck that option if you would like the Administrator to log only errors.

  4. At the end of the wizard, all the configuration options will be displayed so you can confirm by pressing Finish or make changes by pressing the Back button.


Delete Web Application Applications

In the tree view of the left pane, right-click the application you want to delete and select Delete Web Application. You can also select Delete Web Application option from the File menu.


Start or Stop the Web Application Server Service

Start, Stop or Restart the Web Application Server Service

The recommended way to start and stop the Web Application Server service is to use the Start Service, Stop Service and restart Service options found in the File menu of the Web Application Server Administrator.

You may also choose to start, stop or restart only one of the Web Applications. Just highlight the application you need and select Start Web Application, Stop Web Application or Restart Web Application from the File menu.


Monitor Current Activity

Application Activity

Current Sessions

Peak Sessions

Total Sessions

Current Processes

Peak Processes

Total Processes

Client Messages

Server Messages

Time

Last Accessed

Session Activity

Session ID

IP Address

Client Messages

Server Messages

Time

Last Accessed

Process Activity

Slave Node

Client Messages

Server Messages

Time

Last Accessed


Terminate a Session

You can explicitly terminate a session on demand, which is useful in your development stages in the case of hung sessions. To terminate a session, select the Sessions node from the web application in the left pane. Then, right-click the session you want to terminate in the right pane.

Alternatively, select the session you want to terminate in the right pane and, from the Tools menu, select Terminate Session.


Clear the Event Log

Normally, you specify a maximum number of log entries for the event log to prevent the file from becoming too large. When the event log reaches its maximum size, the oldest entry is removed. However, sometimes it is useful to clear the event log on demand. In the left pane, select the Event Log node of the web application you want to clear. You can either use the Clear All Events option from the Tools menu or right-click on the Event Log node and select that option from there.

Alternatively, you can also stop the Web Application Server service and remove the event log file manually. When the service is restarted, a new event log file is automatically created.


Disable a Web Application

You can temporarily disable access to a specific web application. This is useful if you need to update certain components of your web application but you do not want to interfere with or stop other web applications from running on your system.

Right-click the web application you want to temporarily disable and select Stop Web Application. You can also select Stop Web Application from the File menu.

To enable the application Right-click the web application and select Start Web Application or Restart Web Application. Those options can also be found in the File menu.


Scalability Options

Important Concepts and Options

When managing Web or Web Service applications, it is important to understand the concepts of sessions and persistence and how to take advantage of the various scalability options at you disposal. Process Pooling allows you to use your existing server resources much more efficiently. Load Balancing allows you to extend your resources over multiple servers.


Sessions and Persistence

Web Application Server Session

A Web Application Server session is defined as: any user interaction with an instance of a Web Application, from the time the instance of the application is started until the time it is closed. This time range could be from a few seconds, to hours, or even days.

A Web Application is assigned an idle time-out. If no interaction within a specified instance of a Web Application occurs within the time period, it will automatically close down to free up resources for other instances.

Therefore, a Web Application Server session is all interactions of a specific user with the Web Application where a user is defined as any instance of a Web browser requesting information from the Web server.

There could be two instances of a web browser running on a single machine, both interacting with the Web Application. Each web browser instance is considered a separate user, and thus assigned a separate Web Application Server session with a separate instance of the Web Business Process Object.

Persistence

A persistent connection means that a single browser has sole access to a Web Application WBO instance. The DataFlex Web Application Server supports persistence and takes advantage of it to improve performance, but it does not rely on a persistent connection. This is an appropriate model for the Internet because there is no way you can guarantee a persistent connection.

Web Application maintains state information within the ASP session and within the WBO. Although it maintains state information within the WBO objects, it currently does not rely on this persistence. Every time an ASP file makes a request of a WBO, Web Application completely restores the state of the WBO.

This information is based on data that is stored in and posted from the HTML file. Each HTML file contains a record map of the WBO’s DDO structure, allowing that structure to be rebuilt at any point. In addition, each HTML file contains all of the changed data that can be used to alter the DDO structures as needed. Therefore, persistence is not required in a Web Application data entry program. If a session is timed out, the browser can still reconnect to the web server, start a new session/application and proceed with the data provided in the HTML file.

When a web browser makes a request for an .asp file, ASP checks to see if the current user has already started a session. It does this by looking for a cookie in the browser environment.

Special Note

If the browser does not support cookies, it will not be able to support persistence. Your application will still run, but it will be slower, because you will be starting a new program each time you make an ASP page request.

If ASP does not find the appropriate session cookie, it will:

  • Start a new session and application for the user.

  • Start a new instance of the Web Application WBO program.

  • Assign a unique session ID.

  • Store the session ID as a cookie on the browser and then process the ASP page.

If ASP finds the appropriate session cookie (as it would the next time the browser requests an .asp page in the application area), it will process the ASP page using the Web Application Server session that has already started. This session will remain active until the user (or the ASP file) kills the session or a time-out period is exceeded. Once a session is initialized, the Web browser may access any file within the application area and continue to run the same WBOs—no program reloading is required.

Two techniques are available to the developer to enable persistence: cookies and ASP session variables. Neither of these features is used automatically or required, but they can be added to your application. Creating browser cookies is the standard method used for maintaining state in a web transaction. All of your choices are stored in browser cookies, which are not passed to the web server until the entire transaction is processed.

Normally, you are discouraged from saving a great deal of information in cookies. A Web Application does not need to use cookies, but they are there if needed. Session variables are an ASP feature, allowing you to store information for a session at the server. As long as a persistent connection is maintained, your ASP file can query and access the session variables as needed.


Load Balancing

The Web Application Load Balancing feature allows you to distribute your web application over multiple servers. When you use load balancing, your application is distributed over two types of nodes: a single Master Node and one or more Slave Nodes.

The Master Node resides on your Web Server (it resides on the same machine running Microsoft IIS). The Master server is primarily a router. It keeps track of where the Web Application processes (the WBOs) are located, and routes requests to the appropriate server. All your web pages reside on the Web server; therefore they reside on the Master Node.

The Web Application processes are located on Slave Nodes, which run on other physical servers (although this is not required). All communication between Master and Slave Nodes occur via TCP/IP. Each Slave Node runs the Visual DataFlex Web Application processes. Typically a slave node will contain one or more Web Applications, with each application running a pool of Web Application processes. These processes will, in turn, use database tables located either on the same server or on some other server.

There are no programming considerations involved with the use of Load Balancing. Load Balancing is a configuration option. Several different configurations should clarify these options:

No Load Balancing

If you do not use Load Balancing your application will behave as it does with Web Application/2. Your web server and your Web Application processes will all reside on a single server. On a single server you control application scalability by adding multiple and/or faster processors, adding more memory, and by refining your process pooling configuration using the MinPool and MaxPool settings.

Master and a Single Slave on separate Servers

This is probably going to be the "basic" Web Application set up. The Master Node will reside on your Web Server. Since the Master Node primarily acts as a router, it only puts a small load on your Web Server. There will be no DataFlex instances running on the Master Server. Your Slave Server will run all the DataFlex WBO processes. Such a setting is ideal when installing a Web Application on an existing web server. Most all of your application overhead gets transferred off the Web server and on to a slave Server.

The slave server can be used to run a single Web Application, where you would create a separate slave server for each Web Application, or a single slave can be configured to run multiple Web Applications. In fact, a single slave server could be used to run multiple web applications from multiple web servers.

Master with Multiple Slave Servers

A single Web Application can be distributed over multiple slave servers. This allows you to distribute the load of a single application. In such a case, the Master Node will use the various slave nodes, based on a weighted round- robin method. For each web application, the master node will define the location (TCP/IP address and Port) of each slave node and will assign a weight to that slave node.

At this point your scalability options are almost unlimited. In addition, Load Balancing, when used in conjunction with Process Pooling, provides an automatic failure rollover. If an application is distributed over multiple slave servers, and one of those servers goes down, the Master server will direct all requests to the remaining slave servers. Since Web Application processes (which run on the slaves) are assigned on a page by page basis, an application server can fail, and a user (browser client) will never even be aware that the failure occurs. This assumes that the developer has written a proper web application that uses process pooling and does not rely on persistence.


Process Pooling

Before a WBO can be used, the web application containing the WBO must be loaded, the WBO must be initialized and all data tables must be opened. In the previous release of Web Application, this process occurred on a session basis. Session management is built into Microsoft's IIS/ASP server and was created to provide limited persistence over the Internet. The Java Servlet model provides a similar capability. The first time a browser makes a request to a web application a session is started. Future requests from that browser would use the same session. A session remains active until a specified inactivity period has occurred, at which time the session is closed. If the browser makes another request to the same site after a session has closed a new session is created.

Web Application without process pooling uses these sessions to determine when WBOs should be loaded and unloaded. When a session starts, a DataFlex Web Application instance is created (WBOs loaded, initialized, tables opened). This WBO process is uniquely assigned to the session instance. The browser assigned to the session has sole access to that WBO instance. When the session is closed, the Web Application WBO instance is closed.

However, persistence is not that useful in web applications. It's not the way the Internet works. A web application has no real way of knowing when a user is really done. For example a user may visit your site, request a page and make no other requests to your site for 15 minutes. Is the user finished? When should the application close? What is the appropriate time out period? The answer to all of these questions is, you just don't know. For this reason, most professionally written web applications do not rely on session persistence. Each page request is treated as an isolated and standalone event. All information required to request a page and process information is passed to and from the client. Web Application has always worked that way. We advise you not to use session (and therefore WBO) persistence. All our wizards generate code that does not rely on persistence, and none of our samples use session or WBO persistence.

The introduction of Process Pooling better fits the suggested web application model and will do a dramatically better job of managing resources. The two changes made to support process pooling are:

  1. A Web Application process is assigned on a page request basis and not on a session basis.

  2. The Web Application processes are kept in a pool of running instances.

When a browser makes a page request, the Web Application Server goes to its process pool and assigns the request a Web Application process. When the page is completed, the Web Application process is returned to the pool. Since the Web Application process is already loaded, the process of attaching and detaching a Web Application process to a page request is very fast. And, since a properly written page request should be fast, the number of pages that can be serviced by a single Web Application process is much higher. The net result is faster performance with less resource usage. Processes are not being constantly load and unloaded and tables are not being constantly opened and closed.

For example, assume that 100 people direct their browser to your site within a single minute. Without process pooling you will run, at a minimum, 100 sessions each requiring its own Web Application process that must be loaded and eventually unloaded. With process pooling, the same requests can probably be serviced with 3 or 4 processes, and since they are preloaded, performance will be better.

When used in conjunction with Load Balancing, process pooling also provides protection against server failure (a process can be taken from a "pool" that spans multiple servers).

If you have written an application that does not rely on WBO persistence, you can use process pooling without any required programming changes. Since multiple users may now share the same WBO process, events are provided during the attach and detach process to make sure that all data is properly initialized and de-initialized. Normally, you will not need to use these since the default initialization and de-initialization behavior of the WBOs will do this for you. For example, all the Web Application samples work with process pooling without any required changes.

Although most applications will benefit from using process pooling, you are not required to do so. It is possible that some applications work best with WBO persistence. For example, an intranet application being used by a limited number of users may provide an environment where persistence can be used effectively (note that process pooling still allows you to use sessions and any of the persistence provided with session objects.)