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 PowerServer-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.
PowerServer (Web/Mobile) application architecture
Compared with the traditional C/S architecture, the PowerServer 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 PowerServer 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 PowerServer application performance = Web/Mobile client performance + A1 + server performance + database processing performance.
PowerBuilder application impacts vs. PowerServer application impacts
According to the PowerBuilder application architecture and the PowerServer Web/mobile application architecture described above, we know that:
-
PB application performance = PB client performance + database processing performance
-
PowerServer application performance = Web/Mobile client performance + A1 + server performance + database processing performance
PowerServer applications are converted from PB applications and are consisted of two parts after migration: the Web/Mobile client and the server. Therefore, the PowerServer application performance is dependant on the PB application performance.
Two hypotheses as follows:
-
The PB application does not have performance problems; but the converted PowerServer application has.
In this case, the PB client and the database performance expense are negligible. Since the performance of PowerServer 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 PowerServer application converted from it will not have problems either. But under certain circumstances, there still can be performance problems in the converted PowerServer 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 PowerServer 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 PowerServer application have performance problems:
If the PB application has performance problems, the converted PowerServer 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 PowerServer application.
In details, the impacts to the converted PowerServer application are as follows:
Refer to the Impacts to Appeon performance for more information.
