Although Appeon pushes the envelope to deliver unparalleled performance from standard Web technologies (e.g. XML, JavaScript, HTML, Java or C#), which are typically significantly slower than PowerBuilder, slow and latent network connections rob performance from even the best applications!
Network chatter and network-intensive code really highlight the weakness of a poor network connection. Any code that results in a HTTP request (i.e. server call) when executed multiple times sequentially has potential to create network chatter. There are mainly two categories of code that result in server calls - data access related and remote method invocations. Here are several common examples so you can familiarize yourself:
-
Embedded SQL (Select, Insert, Delete, Update, Cursor) including Dynamic SQL;
-
Invoking stored procedures or database functions;
-
DataWindow/DataStore Functions (Retrieve, Update, ReselectRow, GetFullState, SetFullState, GetChanges, SetChanges);
-
DataWindow/DataStore Events (SQLPreview);
-
Invoking a method of a server-side object, such as a PowerBuilder NVO, Java EJB, or .NET Component; or
-
Invoking a Web Service.
Each of the above statements will generate one call to the server utilizing HTTP, with exception of SQLPreview event that will generate one call for each line of code handled by the event. If any of the above statements are contained in a loop or recursive function, well depending on the number of loops, even though its just one statement it would be executed multiple times generating multiple server calls. Needless to say, loops and recursive functions are some of the most dangerous from a performance perspective.
The reason it is important to minimize server calls is because it can take 100 or even 1,000 times longer to transmit one packet of data over the Internet compared to a LAN. Imagine an event handler is triggered, for example handling an "onClick" event, whose execution will result in 80 synchronous server calls over a LAN with latency of 2 milliseconds (ms). In such scenario the slow-down attributed to network latency would be 0.16 seconds (80 x 2 ms). Now imagine this same event handler running over a WAN with latency of 300 ms. The slow-down attributed to the network latency would be a whopping 24 seconds (80 x 300 ms)! And depending on the amount of data transmitted there could be additional slow-down due the bandwidth bottlenecks.
It is imperative for the developer to be conscious that PowerBuilder applications deployed to the Web may not be running in a LAN environment, and as such there will be some degree of performance degradation. How much depends on how the code is written, but in most cases the performance degradation still falls within acceptable limits without much performance optimization.
Should you find that certain operations in your application are unacceptably slow, the good news is there are numerous things that you can do as PowerBuilder developers to ensure your PowerBuilder applications perform well in a WAN environment (e.g. Internet) or on slower networks. At a high-level, your code needs to be written such that the server calls and other performance intensive code is minimized or relocated to the middle-tier or back-end. This will be covered in more detail in the following chapters. Some changes are actually quite simple while others may require increased effort. Nonetheless, in all cases optimizing the performance of your applications in PowerBuilder is just a fraction of the effort to work with typical low-productivity Web tools such as VisualStudio.NET and Eclipse.
