Normal WebHub traffic is syncronous, that is, each request must wait until the one before it has finished. The speed of the Hub and the EXE's serving the surfers ensure that no one is kept waiting. But what if the page being requested requires a database query (or something else that might take a long time)? The EXE handling that surfer makes the query, and then waits for the result, not able to handle any other requests, or even to finish building the page for the waiting surfer, until the lengthy process has completed. At best, the surfer experiences sluggish performance, and at worst, the connection might time out before the page is ever displayed. This is an inherent limitation of syncronous processing.
An asyncronous WebHub App works a little differently. When its main thread receives a request for a page that will require a long time to construct, it spawns a dedicated worker thread to handle the long task, and then can return a page to the surfer informing him of the progress of the request. The App is now free to handle additional requests, either from the original surfer, to whom it can reply with status updates, or from other surfers, in which case it can spawn off additional threads to handle their queries as necessary. When the worker thread finishes processing, its results are made available to the App's main thread, and the worker thread is terminated. The App is then free to pass the results on to the surfer, either immediately, if the connection was kept open, or on the next reload of the page.
HREF Tools recommends the use of the OmniThreadLibrary for multi-threading with Delphi.