The Hub is the process controller within the WebHub System.
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
- 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
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.