JADE System Installation and Configuration

The installation and configuration options you specify for an application can have a significant impact on overall performance.

Some of the options available to you are as follows.

• Thin client

  In JADE thin client mode, the presentation clients are serviced by an application server (effectively a special type of fat, or standard, client), which performs processing on their behalf and transfers over the network only the minimum information required to support the GUI on the presentation client. The application server would typically be located with the database server, allowing a high performance connection between them. Thin client is generally the best option for interactive users when deploying over any network.

  Sending large messages over the network can slow down thin client processing; for example, large graphics or repeated updates of GUI elements. Some GUI constructs can cause a lot of network traffic; for example, the TextBox::change and Form::keyDown event methods. See "JADE Thin Client Performance Considerations" in Appendix A of the JADE Thin Client Guide.

  The thin client trace facility can help analyze thin client network traffic.

• Web browser

  When running HTML thin client mode using the Internet to access applications, JADE generates HTML‑based forms that are accessed using a Web browser. This is similar in some respects to the JADE thin client, except that you are constrained to some degree by the limitations and functionality of HTML and the browsers themselves.

• Fat client

  In fat (standard) client mode, each JADE client performs full JADE node processing (JADE method execution, object caches, and so on) and presentation client functions such as printing. Fat clients should normally be located with the database server, with a high‑performance connection between them; for example, the HPSM or JadeLocal transport. Background processing applications would normally be run as fat clients.

  Performance is typically reduced when deploying over a Local Area Network (LAN) or Wide Area Network (WAN), as the volume of network traffic and network speed impact on performance. See also Distributed Processing, later in this section.

• Server applications

  Server applications run on the database server node. These would normally be system control‑type applications. Database access is faster from the server node, but there are restrictions. For details, see the discussion about the serverExecution method option, later in this section.

  GUI functions, including printing, are not available on the server node.

  It may be easier to stop and restart applications if they are running as fat clients rather than server applications.

• JadeLocal transport

  The JadeLocal transport uses shared memory so it is significantly faster than TCP/IP for nodes located on the same machine as the database server. Application servers and fat client nodes therefore should normally be located on the same machine as the database server if possible, so that they can benefit from the use of JadeLocal or HPSM transport.

• HPSM transport

  The Hybrid Pipe and Shared Memory (HPSM) high‑performance transport was new in JADE 7.0. Like the JadeLocal transport, HPSM uses shared memory so it is significantly faster than TCP/IP for nodes located on the same machine as the database server.

  The HPSM transport has lower overhead, fewer context switches, and higher concurrency than JadeLocal transport.

• 64‑bit JADE

  Starting with the 6.3 release, 64‑bit binaries were available. With JADE 7.0 and later, the database server must be 64‑bit. Application server and fat client nodes should normally be 64‑bit, but they can be 32‑bit if necessary; for example, to use a third‑party DLL that is available only in 32‑bit.

  64‑bit binaries have the following advantages over 32‑bit binaries.

  • Persistent and transient caches can be larger than 2G bytes. Real‑world tests have confirmed that using a 3G byte persistent object cache in a node can improve its performance.

    Contrived tests have confirmed that re‑reading a large amount of data from the database was much quicker in a node with a 22G byte persistent object cache.

  • The limit of 2G bytes of virtual memory per 32‑bit process is effectively removed. This means that cache sizes can be set more aggressively without concern about exceeding the 2G byte limit.

    This especially relates to method cache and string pool sizes, and to the number of server threads in the database server.

  64‑bit JADE provides the ability to address more memory and therefore allocate larger caches. It is important to consider the overall memory allocation strategy when considering the size of a cache. Selecting too large a cache size could result in excessive paging due to insufficient physical memory. As part of this strategy it is important to allow sufficient memory for PDB disk cache.

  External DLLs must be compiled as 64‑bit versions.

  You can run an application server or fat client in 32‑bit mode; for example, if a third‑party DLL is not available in 64‑bit.

• Reorganization fast collection build

  You can specify in your initialization file that fast collection builds should be used. This option causes a reorganization to extract and sort keys to build a collection, rather than inserting them one at a time. For large collections, this can save a lot of random IO.

  [JadeReorg]
  FastBuildBTreeCollections=true
  

  A test was done with three global collections that had 76 million entries combined. All three collections were reorganized by changing a key to descending. Without fast build, the reorganization took 98 minutes. With fast build, the same reorganization took 15 minutes.

  For some restrictions about when this can be used, see Chapter 14, "Database Reorganization", in the JADE Developer’s Reference.

• Asynchronous method calls

  Asynchronous method calls can be used to improve throughput by increasing concurrency.

  A test was done with a number of CPU‑bound tasks and varying numbers of asynchronous worker threads on a machine with 24 CPUs. The total throughput (in terms of calculations per minute) increased as the number of workers increased from 1 to 24. Using more than 24 workers did not provide further improvement, as there was not enough CPU power to support them.

  Another test was done with a number of IO bound tasks. Each task consisted of 2,000 getAtKeys randomly distributed throughout several large global collections. The test was performed on a machine with a high‑end Storage Area Network (SAN). The overall throughput (in terms of getAtKeys per second) increased as the number of workers increased, up to the point where several dozen workers were running.

  One optimization used by high‑end SANs is to maximize concurrency in a Raid 10 (mirrored and striped) configuration, by choosing which disk spindle to read from, with multiple operations occurring simultaneously. The same test was run on a machine with a more‑basic disk controller and a smaller number of physical spindles. The overall throughput reached its peak with about 15 workers.

  In both cases, the IO workers took longer to perform each task, but overall productivity increased due to the increased concurrency.

  For details about asynchronous method calls, see the Asynchronous Method Calls white paper.

• Distributed processing

  Distributed processing refers to locating JADE nodes (fat clients and application servers) on machines other than the database server machine. This can provide performance benefits for larger configurations.

  Locating all nodes on the same physical machine and using the HPSM or JadeLocal transport generally provides the fastest communication path. However, if that machine is overloaded, overall performance may be improved by moving some fat clients or application servers to other machines that have fast network connections.

  Any object retrieval, lock, update, notification, or other message with the database server uses the communications transport, so in general the inquiry nodes should be off‑loaded to other machines and the nodes with heavy updating of the database should be kept local to the database server. This is because updating requires more round‑trip messages between the node and the database server, and you want those trips to be as fast as possible.

  Consider the following code fragment.

  beginTransaction;
      parent.data := dataIn;
  commitTransaction;

  The execution of these three lines requires seven round trips from the JADE node to the database server. These can be measured using the RPC Activity Summary sheet in the JadeMonitor application. The trips are:

  • beginTrans

  • LockObject

  • CommitTrans (commit processing is starting)

  • PutObject

  • endTrans (finalize the updates and make them available)

  • remove Locks

  • returnNotes (sends deferred notifications)

  Each node that is moved to another machine increases the load on the database server, because TCP/IP requires more CPU than the HPSM or JadeLocal transport. Therefore, start by moving a small number of nodes whose function is mainly inquiry. Increasing the size of the persistent object caches in the nodes on remote machines may improve performance by reducing the number of objects fetched from the database server.

  The use of the serverExecution method option is more attractive from remote nodes, as the cost of trips to the database server is greater. Don't overuse it, though, or you will end up with all processing on the database server machine again.

  Scalability is not the only reason for using distributed processing; for example, some systems use a fat client node on an FTP server machine outside a firewall, connected to a database server on a machine inside the firewall.

• Single user application server

  Where you need to have only one application server running, you could consider running in single user mode, which offers better performance over multiuser mode as it does not have the overheads associated with supporting multiple nodes.

  Note that single user and multiuser refer to the number of nodes; not to the number of end‑users. If there are too many end‑users for a single application server or if background fat client nodes are required, single user mode is not suitable.