Smart Thin Client Operation and Performance Considerations

Transcription

1 Development Centre Smart Thin Client Operation and Performance Considerations In this paper... SMART THIN CLIENT OPERATION AND PERFORMANCE CONSIDERATIONS 1 INTRODUCTION 1 SMART THIN CLIENT OPERATION 2 SECURITY CONSIDERATIONS 5 PERFORMANCE CONSIDERATIONS 6 PERFORMANCE RECOMMENDATIONS 7 Introduction The Smart Thin Client provides the ability for users to run applications that use the full capabilities of the Microsoft Windows GUI operations over virtually any kind of network, including the Internet. The user s Presentation Client runs the GUI part of the process and is connected to an Application Server where the logic execution and the database access is performed. This separation also provides an extra level of security so that the database is separated from the user s PC and no database data is ever directly accessible from that PC. Any application executes over the Smart Thin Client. The issue is how fast that system performs. This paper describes the operation of thin client processing and the issues that should be considered when designing and coding such a system. Jade Software Corporation Limited believes that the information furnished herein is accurate and reliable and has been prepared with care. However, no responsibility, financial or otherwise, can be accepted for any consequences arising out of the use of this material, including loss of profit, indirect, special or consequential losses or damages. - 1-

2 Smart Thin Client Operation The Thin Client is made up of: Presentation Client (Jade.exe) that runs on the user s PC and is responsible for the GUI presentation and operation of the forms available to the user. Application Server (Jadapp.exe or Jadappb.exe) that executes the logic associated with the application. The Application Server can handle many Presentation Client connections, each of which runs as a separate asynchronous thread. The Application Server in turn is connected to the database server and is a normal database client. When the user initiates Jade.exe in thin client mode, the Presentation Client establishes a TCP connection to the running Application Server requested. The Application Server signs the user onto the database and runs the initialisation logic associated with the requested application. This normally results in a request to the Presentation Client to display a form. The Presentation Client builds the form based on the information received and presents it to the user. The user then interacts with that form as required. The Presentation Client reacts to the user s actions by sending appropriate requests to the Application Server for it to execute the defined methods associated with those actions. When that logic is executed, the logic may generate additional instructions that are sent back to the Presentation Client to alter the information displayed, and so on. Thin Client Caches The Presentation Client retains a cache file of form definitions it has received (as they were constructed in the painter). When the Presentation Client is initiated, it reads the cache file and sends a list of those forms and their versions to the Application Server. When logic creates a form, the Application Server determines whether the Presentation Client is aware of the current definition of that form. If the Presentation Client does not have the current version of that form, the complete definition must be sent. The Presentation Client then stores that form definition in its cache file. If the Presentation Client does have that current form definition, only a short request to reuse that definition from the cache file is sent. The Application Server also has a cache file that contains any picture images set by logic. This cache file holds only one copy of that image and assigns it an internal identifier. That identifier is sent to the Presentation Client instead of the image data (picture images are usually very large). If the Presentation Client already has that image in its cache file, the image data is obtained from there. If the image is new, a request is sent back to the Application Server to obtain that actual image and then store it in the cache file for future use. Entries in the Presentation Client s cache file are discarded after 30 days of nonuse, by default. The CacheEntryTimeout parameter in the JadeThinClient section of the user s Presentation Client controls that timeout period. - 2-

3 Buffering Processes To achieve suitable performance, where possible the Application Server buffers changes made by logic that affect the Presentation Client (actions that alter some aspect of the GUI presentation in most cases). The Application Server carries a copy of the state of each form, control and menu running on the Presentation Client. Most GUI changes made by logic update the copy of the state of the entity held by the Application Server and adds that request to a buffer that is eventually sent to the Presentation Client. Subsequent logic then interacts with those states as though they were already in effect. The Application Server only sends the buffered requests when it completes the original action initiated by the Presentation Client or when logic requests an action that must wait for the Presentation Client to complete before it can continue. When the Presentation Client receives the list of requests, it processes them one at a time in the order that they were received. The Presentation Client also buffers state changes made by user actions. For example, when the user clicks a list box, this could result in the current active control changing and a different entry in the list box being selected. These state changes must be sent to the Application Server to synchronize its states. These changes are buffered and sent with the next event method request. When the application receives this buffer, it updates its copy of those states and then executes the event method requested. Method Analysis When a form is created by logic, the Application Server determines which of the events actually have a method implemented. This is done for the form and its controls and menus. This information is passed to the Presentation Client. As a result, the Presentation Client only sends event method execution requests for those events that actually have logic associated with them. Note that not all events are analyzed because of the cost of performing that analysis for all possible combinations. Non-analyzed events are always sent. These events are usually those that do not occur frequently. External Function Execution By default, all external function calls are passed to the Presentation Client for execution. Adding applicationserverexecution to the end of the external function definition controls causes the external function call to be executed on the Application Server. If the external function has usage io or output parameters or returns a function value, the Application Server must wait for this external function call to complete before continuing execution. If there is no data to be returned, the external function call is queued and executed when the next buffer of information is sent to the Presentation Client. Printing Printing is also achieved by passing all printer requests to the Presentation Client for execution. This provides the ability to use local printer definitions for all printing. The Application Server buffers all Printer.print method calls to reduce the number of messages sent to the Presentation Client. - 3-

4 File Handling By default, file and file folder handling performed by logic refers to files and folders on the Presentation Client. Setting the property usepresentationfilesystem on a File or FileFolder object controls whether the file is accessed on the Application Server or the Presentation Client. Accessing a file on the Presentation Client is achieved by passing all of the file requests to the Presentation Client for processing. Timers and Notifications Timers and notifications are queued on the Application Server for processing. To execute them directly on the Application Server would potentially create the situation where the application issues requests to the Presentation Client at the same time that the user performs a conflicting action. As a result, the presence of a timer or notification is passed to the Presentation Client and an entry is posted into the Presentation Client Windows message queue. When this queued entry is processed, a request is sent to the Application Server to process the outstanding timer and notifications. - 4-

5 Security Considerations There are three issues where security is a concern for an Application Server: 1. Who is able to connect to the Application Server? 2. Is the information being sent encrypted? 3. What application can a user execute? By default, the Application Server allows a connection from any user, provided that they have the Smart Thin Client software. The only way to control who may connect to the Application Server is to implement an SSL TCP network connection. The user must then have the appropriate certificate by which they are authenticated before the connection succeeds. Three types of encryption can be requested by settings in the Presentation Client or Application Server s initialization file. Turning encryption on for the Application Server overrules the Presentation Client setting. To enable encryption, set the RPCEncryptionEnabled to true. Then set the RPCEncryptionHookDLL option to one of the following: Internal which uses Windows 40 bit encryption (Application Server must be running Microsoft Windows) <dll library name> - you can implement your own encryption in an external dll and that library must be present on both PCs SSL_TLS, which is the supplied SSL TCP connection library To control what application can be run on the Application Server: Use the Application Server initialization file parameter AllowSchemaAndApp<n> to define the specific list of application and schemas that are only available from this Application Server The application must implement its own logon security Supplying your own security library that controls what functions a user may access can control access to the development environment. See the Installation and Administration Guide for details. - 5-

6 Performance Considerations The performance of the Jade Smart Thin Client over use of a normal client will depend on: The size of the messages sent The number of messages being sent between the Application Server and the Presentation Client The speed of the network in use Generally the number of messages sent is the determining factor when the speed of the network is slow due to the TCP message turn-around time. Factors determining the size of the messages sent It is normally recommended that the UseCompression initialization file parameter is set to true even if using an SSL type connection (true is the default). Compression obviously uses processor time at each end of the connection but the decrease in network time is usually more significant. The size of the messages depends on: The number of forms in use. Obviously the more forms, the more controlling requests are required to build and manage those forms The number of controls on each form. Obviously the more controls, the more requests are required to build and manage those controls The amount of GUI logic processed. Each change to a form, control or menu requires a request to be sent to the Presentation Client. While most of these requests will be buffered, each change increases the amount of information that must be sent and processed Factors determining the number of messages sent Messages result from the following: The user performs some action that requires the associated event method or methods to be executed. Obviously the more event methods the more messages that can result Logic that performs a GUI function for which the Application Server must wait for completion. Examples are creating a form, showing a form, setting focus, unloading a form, an external function call that returns information, app.dowindowevents and Window.refreshNow - 6-

7 Performance Recommendations The following recommendations should be considered when implementing an application that will use the Jade Smart Thin Client: Define as much as possible in the painter. The form definition is cached on the Presentation Client after the first create of that form and does not need to be present for future creates. The more controls created or changed at run time the larger the number of requests passed to the Presentation Client and the more chance that additional messages will result. Keep the forms simple. The more controls, the longer the form creation and initialisation overheads and the longer it takes to paint. Avoid defining logic for mousemove events where possible. Mouse move events arrive at a fearsome rate. The Presentation Client actually discards these events based on the initialization option MouseMoveTime in order to limit the interval between such events. Use mouseenter and mouseleave events where possible instead. Avoid defining logic for the keydown, keypress, keyup and change events on controls where possible, especially text box or rich text controls. The time taken to process even one of these events could mean that the user suffers lag behind when entering text. Use the firstchange event if the text box only needs to know whether the text has been changed. For automatic tabbing when the text box becomes full, set the text box autotab property to true. If the logic only applies to certain key types, use the Control.registerKeys method to define the set of keys for which these events will be called. Avoid defining logic for the keydown, keypress and keyup events on forms. The time taken to process even one of these events could mean that the user suffers lag behind when entering text in a text box. If these events are required, use the Form.registerFormKeys method to define the set of keys that the form logic is only interested in. Avoid defining logic for paint events (even though these events are buffered). Paint events occur so often that they can be a significant cause of messages being sent from the Presentation Client. Instead of defining paint events, set autoredraw to true and draw the requirement. The Presentation Client then has all the information locally for redrawing the image. Consider dynamically disabling and enabling events via logic using the enableevent method. An example of this would be that the mousemove event might only be relevant after the user clicks on that window. Be careful with the use of the methods app.dowindowevents and Window.doWindowEvents. These methods cause a message to be sent to the Presentation Client. If logic is repeatedly calling these methods to refresh a display or wait for a button click, for example, the process can end up spending 99 percent of its time doing the dowindowevents calls because of the time it takes to process send and receive the message. - 7-

8 Use Window.refreshNow sparingly, as this method causes a message to be sent to the Presentation Client. It is common for many systems to use refreshnow lavishly for no obvious reason, resulting in poor performance. Sparingly use the other methods as listed in the Installation and Administration guide Thin Client Performance Considerations section that require a message to be sent to the Presentation Client immediately. Most of these are self-evident by definition as they are requesting information specific to the Presentation Client. Sparingly use external function calls that are executed on the Presentation Client. Each such call that returns data causes a message to be sent to the Presentation Client. Use ActiveX and DotNet controls only when absolutely necessary. Accessing many of these controls is essentially no different to calling a series of external function calls that result in an immediate message being sent to the Presentation Client for each access to the control. Note however, that each non- specific event defined for the control is only sent when that event has logic defined. When reading files from a Presentation Client, if the file is opened for input only and sharemode is read only or exclusive (that is the file is static), file operations read data from the presentation client in large chunks and the processing of read request is mostly performed on the app server such that the performance of File.readLine, File.readBinary and File.readString will be comparable. Otherwise, File.readLine is much more expensive than File.readBinary or File.readString. The File.readLine requires multiple messages per line read to reposition the file at the end of each logical line. In addition the larger the size of data read with when using readstring or readbinary, the fewer messages required. Avoid logic that concatenates multiple times onto a window text or caption property. Each time the property is set, a value is passed to the Presentation Client. The logic would be much more efficient if it built the text into a local variable and set the window property on completion. Rather than unload a large form that may be recalled later, consider hiding it instead and reusing it when it is required. This technique could save having to completely rebuild and initialise the form. Use the Control.automaticCellControl feature where possible so that logic is not required to set the contents into a table cellcontrol when the cell becomes active or to set the cell contents when the cellcontrol data is changed by the user. Every picture set at run time is saved in the cache files. To avoid this for temporary pictures, set the Picture.cachePictures property to false. An example of where you might wish to do this, for example, is when createpicture is used to construct an image for a one-off print or display. - 8-

9 Avoid the use of timers of short duration. Each timer execution must be routed through the Presentation Client in order to synchronise its execution with any user activity. Minimize the occurrence of notifications where possible, as notifications must be routed through the Presentation Client in order to synchronize its execution with any user activity Load pictures as png or jpg types rather than type bmp. The png and jpg type files are usually significantly smaller and therefore the transmission time of these types of images is considerably reduced. Consider running the Application Server in single user mode. This can provide significant performance gains by the elimination of the database server node. The downsides of this are that all access to the database must then be performed through the same Application Server. To analyse the thin client traffic generated by the application, set Trace=all in the [JadeThinClient] section of initialization file on the Presentation Client. Initiating the thin client and perform the application actions that you wish to consider. During these actions, a trace file is generated that contains each action sent and received by the Presentation Client. This trace file can then be used to assess the cause of any performance issues. Alternately, consider using multiple Application Servers to share the load of Presentation Clients when there are a significant number of users. When there is a high level of activity on an Application Server, contention for resources and the overheads of thread switching can become significant. To avoid the initial download of forms, the cache file could be generated on a local PC and then distributed to all users. When multiple Application Servers are used, consider using the Automatic Connection Balancing feature. - 9-