A running Gds server consists of several different programs running in parallel and communicating using Query Exchange.
The Mall provides a central directory where client programs register their presence and the location of their "billboard". The purpose of the Mall is to act solely as a directory of programs currently using the Query Exchange
Each program creates one or more billboards. This is an area into which the program places requests for information or actions that it knows other programs will complete. Each program only places requests into its own billboard.
When a running program requires some information or wants something done, such as "Please fetch product #1234", it creates a request and places it in its own billboard. This alerts other programs that something is required and those that can answer repsond with the reply.
This completely frees the source program from how and where the information is processed. It also creates seperation of concepts and avoids excess code being present in every program. Specialised programs can be written to answer very specific requests, such as a "Product Information Program"
The following programs are commonly seen using Query Exchange
For a programmer, the Query Exchange can be seen as a way of extending an application without needing to add more DLLs or code to your program. Need to send an email? Generate a request with the details and place it in the Query Exchange - the responsible program will find and execute it for you.
There are several advantages to this approach:
- Programs only need to learn a data level API, not call level.
- Seperate functions can be isolated to different process space, meaning that failure of one component will not break other components.
- You can start multiple copies of the same program if under high load, subject of course to that program being able to handle multiple copies of itself (most can)
- Very complex functionality can be exposed to programs
- If QueryRouter is present and enabled, requests can be transported to other machines to process.
- Upgrading parts of the system is easier. As Query exchange enforces a clearly defined API, you can upgrade parts of a system without risking others.
- The modular nature makes automated testing easier
Query exchange is able to pass messages at very high rates between processes, but it should still only be used for major tasks. Reading or writing records to a database would be a good use of Query Exchange, but replacing AddTwoNumbers() function would not - the calling overhead is greater than the time to process. However, you might seperate AddTwoNumbers() into Query Exchange if you may wish to replace it in future (eg ExtractTaxFromAmount() )
During startup, the first process to create the Mall also does the following steps:
- Removes the file CrashStartupGds.txt
- Checks total memory is greater than 1Gb, and creates a new file called CrashStartupGds.txt if problems
- Checks current free disk space is greater than 1Gb, and creates a new file called CrashStartupGds.txt if problems
Agent programs will typically create a file called CrashStartupProgram Name.txt during startup to report program specific information, although they are encouraged to append to CrashStartupGds.txt file also.
Systems require at least 1Gb of memory. They will operate below this but performance will be negatively affected.
If using a Virtual Machine, do not allocate more virtual cores than the underlying physical machine. Gds takes different optimisations based on number of CPU cores. If you run a VM with 8 cores on a physical machine with only 2 cores, then Gds will allocate tasks to all 8 cores.
Query exchange will not perform well on single core/single CPU systems, it actively uses programs communicating via shared memory. If you only have one CPU core, the scheduler context switches can degrade performance.
If Gds is running on a NUMA machine ensure that all agents are running in the same group. Gds uses a shared memory interconnect to commuicate between processes
The current Query Exchange request list can be viewed using a browser (if enabled)
This sample shows the following:
- The third line for Pid 3776 shown in red is for a process that has exited. The request is still visible but being ignored. It will disappear when all connections are removed. Blue background is for processes of unknown state.
- There are two requests from a web browser or HTTP client, shown in the first two lines. These requests have been locked by "Files", which in turn appears to have requested more information (the last two lines) which is not currently being answered. The original browser request will be pending not because of the programs HTTP or FILES, but by whichever program is meant to answer the last two queries.