Working against the impact of Internet and slow networks on runtime performance

Network chatter and network-intensive code do highlight the weakness of a poor network connection. Any code that results in a server call when executed multiple times sequentially has potential to create network chatter. Here are several common examples of the code that will result in server calls:

  • Embedded SQL (Select, Insert, Delete, Update, Cursor)

  • Invoking stored procedures or database functions

  • DataWindow/DataStore functions (Retrieve, Update, ReselectRow, ShareData)

  • DataWindow/DataStore events (SQLPreview, RetrieveRow)

  • Transaction functions (SyntaxFromSQL)

  • Invoking a Web Service

Each of the above statements (except SQLPreview and RetrieveRow) will generate one call to the server. If any of the above statements are contained in a loop or recursive function, depending on the number of loops, even though it is just one statement it would be executed multiple times and generate 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 to the bandwidth bottlenecks.

It is imperative for the developer to be conscious that PowerBuilder applications deployed to the cloud 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 cloud environment 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.