Table of Contents
Before we officially introduce the methods to analyze and optimize the performance, we spare a few minutes to look at the possible impacts that cause performance problems to Appeon-converted applications. This helps to learn optimization solutions better, or even helps to work out individual optimization solutions for each application.
Traditional PowerBuilder application architecture
The traditional PowerBuilder application is based on the client/server architecture, in which applications run on the client side and interact with the database with native drivers. The connection between the client and the database (marked as "A" in the following figure) is usually the local area network or high-speed enterprise network, therefore the connection can hardly impact the performance. In this architecture, the main performance impacts are the application and the database.
Thus, the performance of C/S PB applications = PB client performance + A + database processing performance.
Since the connection impact can be negligible, the performance of C/S PB applications = PB client performance + database processing performance.
Appeon (Web/Mobile) application architecture
Compared with the traditional C/S architecture, the Appeon application architecture has a server (that holds the core business logic and the data service) between the client and the database. The client does not directly interact with the database anymore, but sends all the requests and data to the server, and interacts with the database through the server.
In the architecture, the Appeon application performance = Web/Mobile client performance + A1 + server performance + A2 + database processing performance.
A1 is the network connection between the client and the server, and is usually the wide area networks/internet. Therefore, this is a very large performance expense, especially when the client frequently interacts with the server.
A2 is the network connection between the server and the database, and is usually the local area networks or high-speed enterprise networks. The same as that in the C/S architecture, it can hardly impact the performance.
Therefore, the Appeon application performance = Web/Mobile client performance + A1 + server performance + database processing performance.
PowerBuilder application impacts vs. Appeon application impacts
According to the PowerBuilder application architecture and the Appeon Web/Mobile application architecture described above, we know that:
-
PB application performance = PB client performance + database processing performance
-
Appeon application performance = Web/Mobile client performance + A1 + server performance + database processing performance
Appeon applications are converted from PB applications and are consisted of two parts after migration: the Web/Mobile client and the server. Therefore, the Appeon application performance is dependant on the PB application performance.
Two hypotheses as follows:
-
The PB application does not have performance problems; but the converted Appeon application has.
In this case, the PB client and the database performance expense are negligible. Since the performance of Appeon Web/Mobile client and the server are dependent on the PB client performance, the performance problem may be caused by A1, the connection network.
And the possible reasons are:
-
The networks connection is slow or unstable;
-
The data package is too large or the SQL syntaxes are not efficient that result in long communication time in a single communication;
-
The same functionality frequently communicates with the server that results in repeated connection performance (A1) expense, etc.
In the case, developers should: 1) first consider to reduce the communication times between the client and the server so to reduce the connection performance expense; 2) secondly, consider to optimize the efficiency of each communication, for example, by retrieving only the necessary data and using the optimal relational calculus in the SQL syntaxes, etc.
Usually, if the PB application does not have performance problems, the Appeon application converted from it will not have problems either. But under certain circumstances, there still can be performance problems in the converted Appeon application. This is because the PB application will finally run using the machine code or the quasi machine code, which is very efficient at code levels; but the converted Appeon application executes the JavaScript, an interpreted code, and will interpret at runtime. Therefore, the efficiency is lower compared with the machine code, especially when there is
-
Functionalities that use multiple character string manipulation;
-
Lots of loops;
-
Frequently-distributing memories or large memories, for example, large objects, lots of tabpages in the tab control, etc.
-
-
Both the PB application and the converted Appeon application have performance problems:
If the PB application has performance problems, the converted Appeon applications will definitely have performance problems as well.
In this case, developers should:
1) first consider to optimize the performance of the PB application and the database by using all kinds of available system tools. For example, developers can use the transaction track analyser provided by the database provider to analyze and optimize the database performance. Usually, popular database providers provide performance analysis and optimization tools with their databases, developers can use these provided tools to optimize the databases.
2) secondly, after you make sure that the PB application does not have performance problems, use the hypothesis 1 to analyze and the converted Appeon application.
In details, the impacts to the converted Appeon application are as follows:
Refer to the Impacts to Appeon performance for more information.
