Process Controller

Process control instead of system overload

In traditional cgi and ISAPI programming, there are no means to control the flow of exchanged information. The HTTP request from the surfer goes directly from the web server to the program. The program can be easily overloaded by multiple, simultaneous requests from surfers because there is no intermediate stage for surfer requests to be distributed through. A common cause of overload is the use of frames which send multiple requests to the server in rapid succession, just for a single surfer.

As a rule of thumb, if your web application will have any peaks of more than one page request per second, then you need a queuing system and a way to scale up to handle those requests. The Hub provides both.

Why it is so fast

WebHub dedicates the full resources of an EXE to produce the desired page for a surfer, and then moves on immediately to the next request. WebHub uses multi-threading, but does not allow multiple surfers to share the same EXE at the same moment. Instead, it creates the page as quickly as possible, and then lets the next surfer in to use the EXE. WebHub is a queued system, instead of an overload-and-crash system.

In order to minimize potential delays in response time, utilize your Hub instances well and create multiple instances of in-demand or slower EXEs or modules. For example, perhaps you are using an SQL database and some OLE and your pages take 1 second to be created. If you want to support ten page requests per second, you should run ten instances of your EXE.

If you have a multiprocessor machine, you get true parallel processing. On a single processor machine, the applications do take turns, in rapid succession moderated by the operating system. In effect, surfers are processed in parallel, especially if the database is on a separate server. (WebHub v1.34+ supports multiprocessor machines.)

How The Hub works

This applies to WebHub v2

The Hub runs the queuing system by using three key facts about WebHub application servers: the process name, the process handle, and the AppID.

• Process Name -- The process name is defined by Windows to be the name of an EXE. For example, in WebHub Power HTML the process name is aserver.exe.

• Handle -- The handle is defined by Windows when the process runs. It is a location in memory where the process can be found. If you run aserver.exe three times, the process name will be the same in all cases, but the handle will be unique for each instance. So the handle gives The Hub a unique way to reference each instance.

• AppID -- The AppID is an identifier for a set of WebHub HTML files which establish an application's look and feel. When a WebHub process runs, it loads an AppID, thereby assuming a particular look.

Putting it all together -- when page requests come in, The Hub determines the AppID from the URL of the page request. It then checks to see which processes are connected that are serving that AppID and routes the request (by way of the handle) to the least-busy process. If no processes are available and the timeout period elapses, then a customizable error message is returned to the surfer.

How to take advantage of The Hub

Just run more instances of your application server! Each instance will connect automatically to The Hub and be available to handle another surfer in parallel.

Hub capacity and licensing
The Hub is priced based on its capacity.

The Hub capacity determines how many application server instances you can connect and use on that server. The Hub is licensed per deployment-server, at a specified capacity. Developers can start with an entry-level product for prototyping, and then upgrade Hub capacity as site traffic requirements increase. Hub capacity options are 1, 5, 10, 20, or Unlimited.

Performance tip: Isolate your database server
For the best performance, put your database on a separate machine. The application server instance will be "idle" while the database server runs queries, and during those CPU cycles, another application server instance will be able to process another surfer in parallel.

Surfers vs. requests
When estimating your needs, distinguish between the number of connected surfers versus the number of simultaneous page requests. If you have 1000 connected surfers, and they all request 1 page every 10 seconds, then you have only 100 page requests per second.