System 1032
Web Performance - Part 3
by David Stone and Ann Hulsing
You have studied Part 1 of this article (June 98), which described the design of a typical ODBC-enabled Web application. You have considered all the data connection possibilities - application, session, and page level - in Part 2 (July 98).
What can you do to make your System 1032 ODBC Driver application take off?
If your Web application incorporates the design considerations described in this article, you are more than likely to provide speedy delivery of data to your Web site users.
If you can determine in advance the number of concurrent connections needed to access the Web application (expected number of users), consider creating persistent data connections with no timeouts.
This technique is an extension of using shared data connections. You must still manage the connections via the application, but the connections are created only once, which guarantees the fastest response time for the end user.
Much of the information presented on a dynamically created Web page includes objects such as popup menus and pull-down lists. Often these lists contain information that rarely changes, but they are still populated with data saved in a database.
Whenever possible, cache nonvolatile data on the Web server. This frees the application to create the Web pages without additional data connections and without using time to return the display data.
The structures that made for efficient storage and flexible retrieval in your internal application are the very things that slow Web access. The largest performance drag at your Web site is the use of joins. To minimize the use of joins:
When you normalized your data, you removed redundant information from a table and put it into two (or more) tables. Then the remaining information went into a new table. Whenever necessary, you used a unique key in the two original tables to join with the new table.
For example, in a database about employees, department information is often separated from personal employee information. A department ID assigned to each employee is the unique key that joins the appropriate department information back to a given employee.
Denormalizing data reverses this process. You merge data from multiple tables into a single table. The time necessary to create a dynamic join is weighed against the added storage space required;
space is sacrificed for speed. If your data is updated nightly (or less often), consider creating a denormalized summary table that Web users access at your Web site.
Performing joins manually also might give a performance improvement. Consider the following situation. Your database consists of datasets: divisions, departments in divisions, and employees in each department. The Web pages are designed to display a list of employees ordered by division and department. Buttons on the page stand ready to select the next department and the next division.
Data can be returned in two ways:
The series of SELECT statements is often faster than performing the join. It also has the advantage that if a new department is chosen, only the SELECT statement for the employee data need be performed.
The drawback to this technique is that, although multiple SELECT statements are faster at returning the initial data to the end user, they are inefficient for scanning through all the records that can be returned. If you must frequently return all records, then joins are much faster, even on the Web.
The following features, specific to System 1032 ODBC V2, can improve performance.
The relational expression in an SQL WHERE clause or a System 1032 FIND or SEARCH statement is the predicate. For example:
FIND FILM_TILE EQ "The Godfather"
or:
SELECT FROM FILMS WHERE FILM_TITLE = 'The Godfather'
In both examples, the predicate is:
FILM_TITLE = "The Godfather"
Extended predicates employ System 1032 predicates within an SQL statement. The major reason for using extended predicates is because SQL is a case-sensitive language. Consider the following statement:
SELECT * FROM EMPLOYEES WHERE LAST_NAME = 'Smith'
This statement retrieves all values from table EMPLOYEES, where the employee's last name is 'Smith'-not SMITH or smith. To account for those values you must use:
SELECT * FROM EMPLOYEES WHERE LAST_NAME = 'Smith' OR LAST_NAME = 'SMITH' OR LAST_NAME = 'smith'
This statement requires additional processing by the SQL engine and still does not retrieve any employee whose name was entered 'sMith'.
Now, find all variations of Smith using the extended predicates:
SELECT * FROM EMPLOYEES WHERE {PRED LAST_NAME,EQ,'SMITH'}
(The curly braces are required.) This statement uses the System 1032 equivalence predicate, which is case insensitive, and returns all forms of the name 'SMITH'. The SQL engine does no additional processing, which (depending on the size of your datasets) can result in significant time savings.
You can specify these relational operators:
Note: You can use extended predicates only with text data.
To minimize the need to perform dynamic joins, create a System 1032 join view in the ODBC data dictionary. A join view consists of the statements necessary to recreate the join and a saved selection set. The selection set is available as a table to the Web user.
Join views let you process a long or complex view and save the result for presentation. Because no further processing is required, this method is a fast and efficient way to access the data.
You can easily overlook performance improvements in your hardware, including the data server (VAX or Alpha), Web server, and the network.
A data connection is a process on the data server. You need a server of the appropriate size to handle the desired number of connections.
The same is true of the Web server. Additionally, if you are using Active Server Pages (ASP) for IIS, consider implementing as powerful a system as possible. ASP requires considerable amounts of processing power.
Finally, network connections can be a limiting factor as well. Trying to display large amounts of data and/or graphics over a slow network link guarantees poor performance and frustrated users. If you have a slow connection, consider eliminating the use of graphics and restrict the amount of data that is displayed on a Web page.
Is your XMEMSVC installed correctly?
by Henry Lee
When you choose to install the XMEMSVC, you have elected to utilize the cross-memory services and/or IOS BRANCH capabilities of Model 204. After completing the installation of Model 204, you might encounter certain error messages during initialization that could indicate an improper or incomplete installation of the XMEMSVC.
Some of the more common error messages are presented here to help you in troubleshooting.
You might receive one of the following error messages:
If you receive one of these errors, check for the following:
You might receive both of the following error messages:
M204.1378: AUTHORIZATION UNDER APF REQUIRED FOR NON-XMEMSVC SITE
M204.2250: MODEL204 MUST RUN EITHER WITH XMEMSVC INSTALLED OR FROM AN APF-AUTHORIZED LIBRARY
You receive these error messages, if the load library is not APF-authorized and the XMEMSVC is not being used. As an alternative to APF-authorization, you can set XMEMOPT=4 and use the XMEMSVC parameters in the job's CCAIN parameters.
M204.1374: STAE TRAPPED 052 ABEND @ SYSX + 0278
You receive this variation of the M204.1374 error message, if you try to use the Version 4.1 XMEM- SVC at a level of MVS prior to ESA. Because MVS releases prior to ESA are not Y2K compliant and no longer supported by IBM, CCA recommends that you upgrade to a supported release of MVS that is Y2K compliant. In the interim, you can use the Version 3.2.1 XMEMSVC with your Version 4.1 Model 204 Online.
500 Old Connecticut Path, Framingham, MA 01701 webmaster@cca-int.com Copyright 2003
