JADE Thin Client Performance Considerations

When running in thin client mode, you should be aware of the following performance considerations.

• The information required to display a form (determined at JADE paint time) is collected and then stored in the database when possible the first time a form is created. (This is not done for read-only schemas.)

  Subsequent creates of the form then send a request to build that form using the cached build data on the presentation client, unless that form or one of its subclasses has changed.

  You should therefore ensure that all of the forms in deployed systems (including JADE) have had their forms built or generated by accessing all forms for the application. Failure to do so can cause a rebuild and a retransmission of that data to the presentation client on each form create method if the created data cannot be stored (that is, in read-only schemas or for JADE-supplied forms).

• Presentation clients should always be run in the font mode of the application server, which is usually a small font. If the font mode of the presentation client differs from that of the application server, font sizing operations executed from logic must be passed to the presentation client for correct execution (that is, the Window class drawTextWidth, drawTextHeight, getTextExtent, and the control create method where the application default control height must be determined).

• To achieve maximum performance in the JADE thin client mode of operation, the number and size of transmissions to and from the presentation client need to be reduced.

  All events that have defined JADE methods are transmitted to the application server for processing, with the exception of mouseMove and dragOver events, whose presentation client handling is described in the following item. On a slow communications link, this can result in a noticeable turnaround time.

  The thinClientUpdateInterval property of the ProgressBar control enables you to specify in milliseconds how often the progress bar is updated as the percentage changes, preventing an unnecessary number of messages being sent over the TCP connection when the progress updates at a fast rate. (For details, see "Updating the Progress Bar", earlier in this appendix.)

  Key events can also be significant. For example, if a form has keyDown, keyPress, and keyUp event methods and the control with focus also has keyDown, keyPress, and keyUp event methods, six transmissions are required to process the action (or seven transmissions for a text box where the change event also occurs). The use of form key events in JADE thin client mode can have a great impact on performance because of the number of events sent to the application server for every keystroke.

  If performance is an issue, perform one of the following actions.

  • Remove or disable the form key events.

  • Use the Form::registerFormKeys method to declare the set of key strokes that invoke the key events.

  • Use the JadeEditMask control functionality to improve thin client performance by removing validation requirements.

• The MouseMoveTime parameter in the [JadeThinClient] section of the JADE initialization file enables users to specify the time at which mouseMove and dragOver events are discarded when moving the mouse within the same window if the time since the execution of the last move event is less than the specified time defined for the current application, unless the mouse comes to rest. (The mouse comes to rest if no mouseMove events are received for the minimum of the specified time or the default value of 200 milliseconds.)

  If the user moves the mouse slowly enough, the same results are achieved as those when running your application in standard (fat) client mode.

  The first mouseMove event received after left-clicking a control in thin client mode immediately generates a mouseMove event call to the application server (when that control has logic defined for that event). The mouseMove time processing then starts with the next mouseMove event that is received.

  In JADE thin client mode, no mouseMove events are sent to the application server if there is no mouseMove event defined for that window. This mouse move style is transparent to most application operations and achieves a significant reduction of events that are sent. (The extent of the reduction varies, according to the type of move performed.) For more details, see Chapter 1 of the JADE Initialization File Reference, "JADE Initialization File".

  The Painter running in JADE thin client mode uses a fixed MouseMoveTime of 200 milliseconds, regardless of the setting of the MouseMoveTime initialization file parameter.

  In addition, use the Application::getMouseMoveTime method to get the current mouse move time that is in use on presentation clients or the setMouseMoveTime method to dynamically set the current mouse move time for the current application running on presentation clients. (For details, see Chapter 1 of the JADE Encyclopaedia of Classes.)

• All form definitions (presentation cache files) used in the thin client mode are saved in the <jade-temporary-directory>\Jade<modified-application-server-name><application-server-port>.jfm file in the directory specified by the value of the JadeWorkDirectory parameter in the [JadeEnvironment] section of the JADE initialization file of the presentation client that is running the process (unless overridden by the FormCacheFile parameter in the [JadeThinClient] section of the JADE initialization file on that workstation).

  The modified-application-server value consists of any characters that are alpha, numeric, space, underscore, dash, or dot (which are converted to underscores).

  By default, the work file directory is created at the same level as the JADE binary directory (bin) and is named temp. For example, the directory is named c:\jade\temp if the JADE installation directory is c:\jade\bin. The JadeWorkDirectory parameter can specify an absolute path or a relative path (relative to the JADE HOME directory, which is c:\jade in the above example).

  The cache file format enables the same JADE binaries to connect to different application servers and retain use of a presentation client cache file that is specific to the application server and port. Because it is not known whether the previously used cache file is used or required by the initiation of other applications, it is not deleted.

  When a form is displayed in thin client mode, that form does not need to be transmitted to the presentation client again unless it or one of its superclasses has been changed or the form build data cannot be stored.

  When an application is initiated, it transmits the forms it already has cached (and their build versions) to the application server. When form create method is called, the application server needs only transmit a request for that form to be built without having to transmit the form data. This can be significant for a large form or where the form has large picture definitions.

  This stored data is used across sessions. The first access of a form can take a significant time over a slow link when the form definition is transmitted initially.

  To overcome this initial delay, you can generate the form in a local thin client environment and then include the generated file in the distributed client installation files.

  Set the UseCacheFile parameter in the [JadeThinClient] section of the JADE initialization file to false, to specify that form and picture caching is not used on a presentation client. By default, forms and pictures are cached, as performance is significantly improved when form and picture information is cached on most connections. However, on a high-speed LAN where caching may not be necessary, setting this parameter to false transmits form and picture data in full to the presentation client, instead of creating a cache file.

  For details about discarding picture and form entries in the presentation client cache file, see "CacheEntryTimeout" under "JADE Presentation Client Section [JadeThinClient]", in the JADE Initialization File Reference.

• JADE skins use a facility similar to form build data. When the app.setApplicationSkin or Form::setApplicationSkin method is first called, the collected skin data is stored as a blob on the JadeSkinApplication instance. Subsequent calls then do not need to retrieve the skin information, and use the stored information.

  In addition, a presentation client caches the skin information. As a result, subsequent calls of the app.setApplicationSkin or Form::setApplicationSkin method only need to request the creation of the skin from the presentation client cache file without having to transmit the skin data.

  Changing a skin definition using the JadeSkinMaintenance form or by loading a form and data definition (.ddb or .ddx) file will update the timestamp of all JadeSkinApplication instances so that a rebuild of the skin information will be required the first time each skin is set for an application or form. If you change JADE skin information by any other means, you must call the updateSkinTimeStamp method on the JadeSkinApplication instance, to reset the instance timestamp and cause the skin build data to be rebuilt.

• All picture properties set by logic are cached on both the application server and in the form file on the presentation client. When a picture has been transmitted to the client, subsequent use of that picture can be achieved by use of an identifier to that picture, eliminating the need to transmit the picture data.

• When the contents of a text box change, only changed text is transmitted to the application server.

• If the connection speed is low, disable the Debugger bubble help when stepping through code in thin client mode, by clicking the Bubble Inspector check box in the Debugger Options dialog.

• All JADE logic GUI set property calls are buffered. The application server validates the property change and queues the change request for future processing. The changes are processed when a subsequent request requires interaction with the presentation client or the current processing is complete.

  This buffering process should be transparent to the user and any logic, as the property values always return the values as if they had been applied immediately. (For details about forcing visual changes to be applied at some logical point before the current processing is complete, see "Flushing Commands Queued in the Application Server", earlier in this appendix.)

• Most GUI property value read requests have the required data available within the application server environment, eliminating the need to access the presentation client for that information.

  Even if you are not operating in thin client mode, it is much more efficient to copy a GUI value into a local variable for reuse rather than request the value again. For example, listBox.listCount requires the calling of a list box method to retrieve the value.

  Storing the value in a local property for reuse avoids a significant overhead for the second and subsequent requests for that value when it will not change. The first of the following examples is much more expensive than the second of these examples.

  while count <= listBox.listCount do // inefficient use of the variable
  
  
  vars                                // recommended use of the variable
     drag : Integer;
  begin
      drag := keysList.dragListIndex;
      if drag <> -1 then
          keysList.addItemAt(keysList.text, drag);
      endif;
      keysList.listIndex := drag;
  end;

• The following actions, get property requests, and method calls require communication with the presentation client and must wait for a response from the client.

  • Any form creation

  • Any external function call executed on the client that returns a value or has usage io or output parameters

  • node.createExternalProcess

  • app.doWindowEvents or Window::doWindowEvents

  • app.getIniFileName

  • app.getProfileString

  • app.getJadeInstallDir

  • app.setProfileString

  • Any application start (that is, the startApplication, startAppMethodWithString, startApplicationWithParameter, or startAppMethod) method

  • Window ::drawSize

  • Window class drawTextHeight, drawTextWidth, and getTextExtent methods when the application server and client default font settings differ (that is, small fonts versus large fonts)

  • Window::getPoint

  • Window class left, top, width, and height property values must be refreshed after changes where these values may be affected by relative positioning or parent modification

  • Window ::refreshNow

  • Window ::setFocus

  • Window::showHelp

  • Form ::popupMenu

  • Form::show or Form::showModal

  • Form::unloadForm

  • Control ::createPicture

  • ComboBox ::isDroppedDown

  • ComboBox::selLength

  • ComboBox::selStart

  • ComboBox::selText

  • ListBox ::getScrollRange

  • Any MultiMedia class get property request or method call; for example, position

  • Any Ocx or ActiveXControl class get property request or method call that returns a value or has a usage io or output parameter

  • Any OleControl class get property request or method call

  • Picture ::pictureHeight

  • Picture::pictureType

  • Picture::pictureWidth

  • Table ::expandedHeight

  • TextBox ::lineCount

  • TextBox::getScrollRange

  • TextBox::selLength

  • TextBox::selStart

  • TextBox::selText

  • Binary ::convertPicture or Binary::convertToFile

  • OleObject ::isServerRegistered

  • Application ::isActiveXClassIdRegistered

  • FileNode class operations executed on the presentation client

  • Printer class property or method request that must be obtained from the presentation client

    When the presentation client requests a print preview, the pages of the printed report do not have to be transferred to and from the application server. (This optimizes the performance of the print preview process when running JADE thin client mode over a slow network.)

    However, if your application calls Printer::setReport to indicate that user logic subsequently stores or manipulates the report output, each page of output is transferred to the application server.

See also "Enhancing the Performance of Windows and Forms", in Chapter 3 of this document.