Important Information Regarding Pro for the Web Running In Client/Server Mode

Introduction

QAS Pro for the Web versions 3.01 and later have the option of running in Client/Server mode. In this scenario, multiple web servers may be connected to multiple QAS Servers (QASVs) via TCP/IP, which will perform the required address lookups.

The QASVs exist as a Windows service or a UNIX server daemon to which the Pro for the Web product will connect.

This document assumes some familiarity with the standalone Pro for the Web product and the QAS Server.

Advantages of client/server:

• Load sharing and fail-over: if a QASV goes down, load is automatically switched to other QASVs with no human input required. During normal operation the system will be load shared so that searches are sent to the server with the lowest current processing.
• CPU usage on the web server machines will be considerably reduced compared to the standalone web product, allowing the majority of their time to be taken up with serving the web site.
• For a setup involving many web servers (web farms), having one or a small number of centralised QASV will considerably simplify administration of the product as data updates only need to be performed on these machines and not every web server.

When to consider the standalone Pro for the Web product rather than client/server:

• All other things being equal, the Client/Server product is slightly slower per search than the standalone product due to the small overhead of network transfer.
• If you intend to implement a Microsoft DCOM layer to provide the client server functionality, then the standalone product is written to take advantage of this. In other words the ActiveX interface of the standalone Pro for the Web product can be exploited by DCOM with no further requirement from the QuickAddress product. Certain versions of DCOM can provide fail-over and load balancing also.

Configuring Pro for the Web to run in Client/Server mode

You must have at least one QASV program (qapwsv.exe) installed to set up Pro Web Client/Server.

You should locate the file QAWORLD.INI in the Pro for the Web installation directory on every Web server that needs to use this configuration. This should not be confused with the QAWORLD.INI in the QASV installation directory. In the Pro for the Web QAWORLD.INI file insert these lines at the top of the file under [QADefault]:

ServerAddress=QATCPIP:[Server Name or IP address]:[Server Port]

+QATCPIP:[Second Server Name or IP Address]:[Second server port]

+QATCPIP:...

For Example:

ServerAddress=QATCPIP:MyQASServer1:2021

+QATCPIP:MyQASServer2:2021

+QATCPIP:MyQASServer3:2021

This will configure the product to use three QASVs in a load sharing way, each listening on port 2021.

There is no restriction on the number of QASVs a particular installation of Pro for the Web uses.

You can see the number of currently active clients (i.e. a measure of the web activity), as well as the current internal network traffic by running the Administration Console program in the QASV installation which runs on Windows (UNIX users may be using the command-line management console although you will have a copy of the Windows-based version). An example is shown below:

The number of client connections to each server is dependent on the current website activity. Initially the product makes one connection for each country installed on the server plus one spare but this will increase considerably once searches start to be performed. However, the number of connections will never approach the total number of current website users as the actual time spent performing searches will be a fraction of the time a user is accessing the website (maybe as little as 1% of the time).

Important information when changing from standalone to Client/Server configuration of Pro for the Web

Multiple country layouts

Although operation of multiple QASVs with differing country/layout combinations is technically allowed, it is strongly discouraged due to the fact that load sharing could allocate a QASV randomly to a particular search which may have a differing layout to another – leading to unpredictable results. The most efficient way to overcome this is to run the configuration utility (qacfgwn.exe) on one of the QASVs and ensure that the ServerAddress setting in the QAWORLD.INI file local to that program is the same as for all the QAWORLD.INI files for all installations of Pro for the Web. When the layouts are configured using the configuration utility, it will check for the most recently updated server, use these settings initially, and then update ALL the servers in its list upon completion.

Security considerations

As Pro for the Web may be running on a public computer, security is a prime consideration. Pro for the Web itself can only act as a TCP/IP client, and so does not offer any particular security risks. But the server has no special protection on the port it listens to, and so an attacker could execute denial of service if they had access. Further, if they had QAS server tools (the Administration Console or the Configuration Utility), it would be trivial to shutdown the server & so stop Pro for the Web operating .

Therefore we most strongly recommend that the QASV be protected from the outside world via a firewall which blocks all TCP/IP traffic on that port coming from ‘outside’. Although this will prevent configuration and administration tasks from being performed remotely, this can be worked around by using the tools on the QASV machine itself via a remote desktop tool. Network administrators might use SSH or another similar TCP/IP tool to tunnel the QAS Client/Server connection through the firewall.

Default layout with example pages

If you are changing a standalone installation to run in client server mode you should note that the Pro for the Web example pages will likely fail at the point at which the final address is returned to the screen. (See below)

This is because the default layout that is used in the standalone product’s example pages is the ‘Database Layout’. When running Pro for the Web in Client/Server mode, the layout to be used must exist in the QASVs’ QAWSERVE.INI rather than the Pro for the Web QAWSERVE.INI (see ‘Multiple Country Layouts’ above). The Database Layout does not exist by default in the QASV ini file – resulting in the above error.

To rectify this you should copy all of the text below the heading

[Database Layout]

in the Pro for the Web QAWSERVE.INI file (including the heading itself) and paste it into the bottom of the QASVs’ QAWSERVE.INI file. The service must be restarted following this action.

Stress testing

Experian QAS recommends stress testing your setup of Pro for the Web Client/Server before deployment in a live environment at levels at least equal to the maximum anticipated load on your website.