Application Server Considerations
To take full advantage of the PL/B Application Server, the programmer should:
Remember that there is communication link in the process particularly if using the Internet. The Web can sometimes provide outstanding performance while other times it may not.
Pay particular attention to the server configuration. Individual servers responsible for specific applications may lead to improved performance.
Since the Window's help engine knows nothing about the Application Server, application help must be implemented using an alternative solution. An example of such a solution is available on the Sunbelt Forums.
The Application Engine and Client Interface use buffering technology to maintain quality performance. The application programmer should design programs destined for the Application Server with that technology in mind.
Note the Following:
1. The PLBSERVE/PLBCLIENT PL/B program execution is optimized to minimize the network message traffic when possible. As a program is executed, the PLBSERVE runtime detects what instructions can be buffered and what instructions require immediate action. Instructions maybe buffered until either the message buffer is overflowed or until a non-buffered instruction is encountered at which time a single message is sent to the PLBCLIENT task to be processed. This technique provides the best means of minimizing the number of messages sent between the server task and a client.
Any statement that does not return a result or any error will be buffered. These include such statements as:
DISPLAY, SETMODE, WINHIDE, WINSHOW, WINERASE, WINREFRESH, SETWTITLE, ACTIVATE, CHECKITEM, DEACTIVATE,
DELETEITEM, DISABLEITEM, DRAGITEM, ENABLEITEM, DESTROY
The following statements are always buffered for all GUI objects except for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects. Buffering is not applied when these statements are used for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects.
EVENTREG, INSERTITEM, and SETITEM
The following statements are always buffered for all GUI objects except for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects. Buffering is not applied when a COLLECTION object is used. However, buffering is used for AUTOMATION, CONTROL, NETOBJECT and NETCONTROL objects only when these statements are grouped together and in this case, these statements can be mixed.
SETPROP, and OBJECT METHODS with no result returned
2. The GETITEM statement is optimized to allow buffering. When multiple GETITEM statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks.
3. The PLBSERVE runtime is designed to execute most PL/B programs with minimal or possibly no changes. However, PL/B program techniques that appear to work well while using PLBWIN on a single workstation may not provide the best performance for a PLBSERVE/PLBCLIENT. Avoid creating unnecessary objects and preloading object data that may only be used occasionally. Be aware that using PLFORM and FORMLOAD objects can also be more efficient than using individual CREATE operations.
4. The CREATE statement is optimized to allow buffering. When multiple CREATE statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. This type of buffering does not occur on the creation for WINDOW, FONT, or COLOR objects.
5. Be aware that the CONTROL objects are only created and used at the client workstation. Any resources or data required for the control must be available at the client workstation.
6. If the PLBWIN_ICON={iconfile} keyword is used in the PLBSERVE.INI file, the client main window will use the specified icon. If the {iconfile} name begins with an '!' character, this specifies that the icon file being used must exist on the client.
7. The PLBSERVE runtime must be installed on a server before it can be used. The number of client connections that can logon to the server is by the authorization number specified during installation. The licensing is by connections and not by users. A single workstation running three plbclient tasks counts as three connections.
8. The GETPROP statement is only buffered when the SETMODE *SRVBUFMODE keyword is set to a level 2. This mode allows a group of GETPROP statements to be buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. The SETMODE *SRVBUFMODE=2 works in a one shot manner. Once a user has verified that a group of GETPROP instructions does not have any interactions that can cause unexpected results, a SETMODE *SRVBUFMODE=2 statement can be executed immediately prior to the first GETPROP statement in a group. Once the group of GETPROP statements have been sent to the client, the SETMODE *SRVBUFMODE reverts back to a previous level when a PLB instruction other than a GETPROP is encountered. The user application must execute another SETMODE *SRVBUFMODE=2 when there is another group of GETPROP instructions to be sent as a group.
See Also: Introduction
|